A limit for heterotroph bots, and normal veggie repro

[Welwordion]

For  Evo sim I like to run bots as veggies so I can limit thier number, however I read somehwere there is a certain fail chance for veggie reproduction and indeed there are some bots who do not reproduce correctly when turned into a veg, so give me  a limit option for normal bots plz and an option to remove this fail chance.

[EricL]

All veggies are prevented from reproducing when their population is above the limit.  When below the limit, a random 10% of veggies are allowed to reproduce each cycle.  If this is not what you are seeing, it is a bug.  

Without this limititation, all veggies would be allowed to reproduce in the cycle in which the population falls below the limit with the result that the actual population in the sim would approach twice the actual specified limit.

Why are dynamic costs insufficient for controlling hetertroph populations?

[Welwordion]

Well, I am using several setting schemes where negative costs are used to provide evolving bots with energy,
(mainly if I start with Zero or Randombots) as such higher cost would actually mean more energy for the bots
(tried to put negative values in the dynamic cost but either I did it wrong or it does not work)
but cause of the 10% repro rule of veggies I can not just simulate my bots as veggies.

( I often introduce shepherd bots, bots that fire at nearby bots but are fixed and do not mutate or reproduce.
I  sometimes try to combine this with light gravity to force the bots to invent escape movement, but you need a high shepherd density and lot of manual interfering to prevent black holes, and if you put age cost on its not calculated per body so its hard to fit this to body cost in a way shepherds are not affected to much, which is a reason you prefer running your bots as veggies as you can give them a numerical energy. Though I guess I can simple use the veggie respawn for that matter )

[EricL]

Well, I am using several setting schemes where negative costs are used... (tried to put negative values in the dynamic cost but either I did it wrong or it does not work)

I explictly prevent negative values for the cost multiplier.  I was not aware anyone was using negative costs.  I could change this so as to allow the cost multiplier to go negative.  If I did this, then you could make all your costs positive, using a negative multiplier and then allow dynamic costs to move it up or down to maintain your population in a specific range....

but cause of the 10% repro rule of veggies I can not just simulate my bots as veggies.

I'm still not sure I follow you on this.  Yes, assuming the population is below the limit, there is a 90% chance a bot won't be able to reproduce when it tries to, but in the aggregate, bots that exhibit better reproductive fitness will still do better.  Is this really a problem statisticly speaking?

( I often introduce shepherd bots, bots that fire at nearby bots but are fixed and do not mutate or reproduce.
I  sometimes try to combine this with light gravity to force the bots to invent escape movement, but you need a high shepherd density and lot of manual interfering to prevent black holes, and if you put age cost on its not calculated per body so its hard to fit this to body cost in a way shepherds are not affected to much, which is a reason you prefer running your bots as veggies as you can give them a numerical energy. Though I guess I can simple use the veggie respawn for that matter )

Hmm.  In my evo sims, I generally don't use costs at all.  They select for nrg effeciency yes, but this often leads to selection for smaller genomes adn bots that do less and less in my sims.  Instead, these days I use shepard bots as the exclusive means of population control.  I just take the baddest, boldest, most aggressive bot I can find and turn him into a shepard that limits his own popualtion (using .totalbots and .totalmyspecies) and only hunts when the popualtion as a whole climbs above some threshold.  In soem cases, I turn them into care givers if the popualtion falls too far, having them shoot the evo bots with nrg shots...

Would you be cool with simply letting the cost multipler go negative?  I suppose I could add an option to allow the user to specify the percentage of veggies that will be randomly allowed to reproduce when the population is below the threshold (you could choose 100%) but I dislike adding more knobs to the UI.  Things are too complex already.

[Testlund]

I suppose I could add an option to allow the user to specify the percentage of veggies that will be randomly allowed to reproduce when the population is below the threshold (you could choose 100%) but I dislike adding more knobs to the UI.  Things are too complex already.

I think this would be a good idea actually. Personally I didn't have any big jumps in populations before you added this limit, (maybe just a few 100 for Alga Minimalis when they were below the upper treshold). Also with evolved bots they don't tend to reproduce exactly at the same time anyway. So I find it a little unfair that some godly power just point to a veggie telling it 'you may reproduce'.  

There's room for one more function in the Population Control square on the general tab.  

[Welwordion]

Ah using negative values for the cost multiplier? Hmm let me think when its raised it abs becomes less and when its shrinked it becomes more , which fits the case for cost rewarding.
Yeah you could do that .
edit:
Ups just realized that dynamic cost are not really worth anything to prevent cancerous bots from multiplying like crazy and trough that to slow down the simulation.

[Numsgil]

You might want to generally reorganize the settings tabs, or reorganize the way they work period.  The ideal method would be to have a "basic" screen that prompts new the user for values-- easy to understand and use, but not necessarily complete.  And then have an "under the hood" options panel, that lets you tweak all sorts of crazy stuff.  Or you could even have settings be stored in text editable files, and "advanced" features would be edited in the actual file.

[EricL]

I think this would be a good idea actually. Personally I didn't have any big jumps in populations before you added this limit, (maybe just a few 100 for Alga Minimalis when they were below the upper treshold). Also with evolved bots they don't tend to reproduce exactly at the same time anyway. So I find it a little unfair that some godly power just point to a veggie telling it 'you may reproduce'.  

Well, I guess I just have a personal bias against evolving veggies.  It strikes me as.... cheating.  I prefer to use other means to provide fledgling zerobots with an nrg supply.  But, that said, if one is going to evolve veggies, then I concede you have a point here w.r.t. fairness.

There's room for one more function in the Population Control square on the general tab.  

The issue isn't physical space on the tab (though we are at the VB control limit on the dialog as a whole - I'll have to move something else off the dialog).  The issue is just overall complexity.  Too many knobs to turn.  I'm with Steve Jobs.  I hate buttons.  Look at the simplicitly and approachability of the IPod or IPhone.  DB has too many knobs IMHO.  Every knob is a barrier for new users, a place for erronious errors and misunderstandings to crop up.  Somethign to document and explain, over and over.  This one would be a doozy!  A fertile place for user problems.

Would you guys be okay if I instead built in some interal logic to address this instead of exposing more knobs?

Lets say I enforce the 10% rule for only a few cycles, the few cycles following when the veggy population drops below the threshold.  If the population stays below the threshold for say 5 cycles, or say, drops more than 10% below the threshold, then I'll let them all go.

This has the advantage of preventing veggy overpopulation in sims where veggies are just food but allows for more fairness in sims where people are breeding veggies.  And, it exposes no new UI...

You might want to generally reorganize the settings tabs, or reorganize the way they work period.  The ideal method would be to have a "basic" screen that prompts new the user for values-- easy to understand and use, but not necessarily complete.  And then have an "under the hood" options panel, that lets you tweak all sorts of crazy stuff.  Or you could even have settings be stored in text editable files, and "advanced" features would be edited in the actual file.

Sounds like work.  I hate work.  

[Testlund]

[Well, I guess I just have a personal bias against evolving veggies.  It strikes me as.... cheating.

Hmm... I don't follow you there. I have nature as my guidence when I evolve my bots. First there were the ones that lived on carbone dioxide and sunlight, then others evolved from them after oxygene increased in the atmosphere, therefor I want to start with veggies and later on split them into two goups, autotrophs and heterotrophs. So now I run two instances with heterotrophs in the left and autotrophs in the right sim.

Lets say I enforce the 10% rule for only a few cycles, the few cycles following when the veggy population drops below the threshold.  If the population stays below the threshold for say 5 cycles, or say, drops more than 10% below the threshold, then I'll let them all go.

This sounds like an even better idea, or let more percentage reproduce the lower the population is under the upper treshold.

Sounds like work.  I hate work.  

I've been thinking about posting a list about some issues...  

[EricL]

[Well, I guess I just have a personal bias against evolving veggies.  It strikes me as.... cheating.

Hmm... I don't follow you there. I have nature as my guidence when I evolve my bots. First there were the ones that lived on carbone dioxide and sunlight, then others evolved from them after oxygene increased in the atmosphere, therefor I want to start with veggies and later on split them into two goups, autotrophs and heterotrophs. So now I run two instances with heterotrophs in the left and autotrophs in the right sim.

Actually, animals predate plants (by animals, I mean organisms whose metabalism and nrg aquisition does not depend upon photosthyisis).  But that's a little orthoginal.

What I meant is that getting nrg without doing anything creates different selective pressures than the need to aquire nrg through action.   If you are a veggie, selection favors being conservative.  All you have to do to survive is not get killed and be effecient in doing that relative to costs.  In my expereince, this leads to smaller genomes and organisms that do less and less.   If are not a veggie, then you must seek out nrg or die.  Seleciton favors strategies to do this.  Early on this can mean simply gettng closer to nrg shooting shepard bots.  Later on, it can select for tie feeding, active hunting, etc.

So, what I meant is that I have a personal bias against the kind of adapataions and behaviour (or lack there of) free nrg for nothing encourages.  But I acknowledge others may not share this.

[Welwordion]

Well however you assume your bots already have learned to shoot other bots in order to increase their energy, if they do not have a way to nourish themself each generation will lose energy by costs or dieing until no energy is left within the system.

Also I think whats really making Darwinbots is ,are  not visible undocumented mechanisms.
I mean come their is so much stuff you just do not know about the way bots and physics  work without extensively searching the forum.

My suggestion is instead of seperating veggies and bots per se give me the option to make "classes" of bots
I then choose certain properties for them and in the menü choose which class a bots belongs to.
That way you could make more diversity without making properties invisible.

Also I always thought that it would be nice if the forces between bots could be a little more complex then justplanet eaters, maybe even with with the possibilty for bots to create pseudomass, charge for a certain energy cost?

[Numsgil]

You probably already know this Eric, but in case you don't: the limit on the number of controls is for the number of handles, not the actual number of controls.  Meaning you can make a control array and dump 3 or 4 things in to it, and free up that many spaces.  Since the control arrays can be unlimited in size, the limit only forces you to do things a little differently.  For some controls, arrays might not be a good idea, but for things that are passive, like labels, you can clear up all sorts of control slots by dumping all of them in to an array.

That said, I agree the options form is cluttered.  It's been like that since before I joined.  The current "advanced physics" window was part of my plan to create a "newbie" interface that's really dumbed down, and get people to edit "advanced" options in other panels.  The problem is that it's hard to sync the two all the time, and so it creates all sorts of bugs that are hard to reproduce.

You worked at Microsoft, what's Microsoft's general strategy for user editable options?  Most Microsoft software I use is generally pretty user friendly in that regard.  I keep thinking that there's some sort of design pattern for GUI elements like this, like there are for class design, but if there is I've never found them.

So I don't have any answers, but this is definately an area for improvement.  But it's been hobbled together for years, it can stay hobbled together for years more.  Won't kill anyone, anyway

[EricL]

You probably already know this Eric, but in case you don't: the limit on the number of controls is for the number of handles, not the actual number of controls.  Meaning you can make a control array and dump 3 or 4 things in to it, and free up that many spaces.  Since the control arrays can be unlimited in size, the limit only forces you to do things a little differently.  For some controls, arrays might not be a good idea, but for things that are passive, like labels, you can clear up all sorts of control slots by dumping all of them in to an array.

Turns out the limit in VB is on actual controls be they in arrays or not.  Putting controls in arrays doesn't impact the limit.  I've tried it.  I think VB control arrays are just a convience for addressing as far as I can tell.  I'm pretty sure each control in an array still has it's own underlying Windows handle for tabbing, short keys, etc.

You worked at Microsoft, what's Microsoft's general strategy for user editable options?  Most Microsoft software I use is generally pretty user friendly in that regard.  I keep thinking that there's some sort of design pattern for GUI elements like this, like there are for class design, but if there is I've never found them.

I'm a systems guy, not a UI guy, but it was always a constant struggle to keep the UI simple in everything.  Some groups are better than others, but I always thought Microsoft sucked at this in general.  The knee jerk reaction, especially for enterprise apps and server admin stuff, was always just to expose another knob adn push the problem onto the customer's shoulders.  The argement/defense was that there was always some customer who supposedly needed (or thought they needed) to tweak thread priorities or garbage collection schedules or something like that themselves.  Generally, they never did.  You see half-baked attempts in Microsoft products to simplify the underlying complexity such as the auto-shrinking menus in Office.  Sounds good in therory, ends up terrible in practice.

My personal philospoghy is that if you can make it work, less UI is generally better UI.  Not always of course, but in general.  Every knob costs 10 times the code effort in documentation, user support, bugs, locaization, accesibility, and so on.   Exposing knobs is the easy path for the coder/designer, the cop-out route.   It actually takes more code, smarter code and more up-front thinking to make things elegant and auto-sensing or whatver it needs to be to not expose the knob, but in the long run, it's the right choice were it can be made.  Apple is very good at this.  Microsoft, not so much.

[EricL]

Well however you assume your bots already have learned to shoot other bots in order to increase their energy, if they do not have a way to nourish themself each generation will lose energy by costs or dieing until no energy is left within the system.

I assume no such thing.  I have run many zerobot sims using everything from everlasting nrg shots to benevolent shepards to supply nrg to my fledgling hetertophs until they learn to reproduce and do something to aquire nrg, even it that something is nothing more than blind reproduction.  ALways reproducing means you will reproduce when you can, generally when yoru body >2, which happens when you get near an nrg source like a bleednrg bot.  This alone is enough to allow first replicators to surive without being plants and to do so with costs....

Also I think whats really making Darwinbots is ,are  not visible undocumented mechanisms.
I mean come their is so much stuff you just do not know about the way bots and physics  work without extensively searching the forum.

This is true and you make a good implict point that the algorithm would have to be documented on the Wiki.

My suggestion is instead of seperating veggies and bots per se give me the option to make "classes" of bots
I then choose certain properties for them and in the menü choose which class a bots belongs to.
That way you could make more diversity without making properties invisible.

A species is just such a class.  We use the term species like it means something.  All it means in an evo sim is bots in this class had the same distant ancestor with the same set of starting properties.  After the first cycle, every bot has it's own state - it's own mutation percentages, etc.

Also I always thought that it would be nice if the forces between bots could be a little more complex then justplanet eaters, maybe even with with the possibilty for bots to create pseudomass, charge for a certain energy cost?

Sounds interesting.  I'm all for more complexity.   But doesn't shell/body essentially provide this today? I.e. a way for a bot to turn nrg into mass?    BTW, Planet eaters is terribly costly from a computation perspective as it is O(n^2) as currently implemented.  It can slow a sim down by 100% or more.

[Numsgil]

You probably already know this Eric, but in case you don't: the limit on the number of controls is for the number of handles, not the actual number of controls.  Meaning you can make a control array and dump 3 or 4 things in to it, and free up that many spaces.  Since the control arrays can be unlimited in size, the limit only forces you to do things a little differently.  For some controls, arrays might not be a good idea, but for things that are passive, like labels, you can clear up all sorts of control slots by dumping all of them in to an array.

Turns out the limit in VB is on actual controls be they in arrays or not.  Putting controls in arrays doesn't impact the limit.  I've tried it.  I think VB control arrays are just a convience for addressing as far as I can tell.  I'm pretty sure each control in an array still has it's own underlying Windows handle for tabbing, short keys, etc.

Au contraire.   I have many warm, happy, fuzzy memories of moving labels from free floating to control arrays to free up room for new controls.  Ah, the hours wasted...  Anyway, you can find some informal proof in these discussions, where it's mentioned as the way around the limit.  Not that I'm saying we need more controls!

I think we need to take a Thoreau view towards GUIs and simplify, simplify, simplify.  But at the same time some functionality needs to be modifiable outside the source code, for specialized needs.  I'm not sure what a good solution is.  However, in general, these are the guidelines that I work with (in general, not just Darwinbots):

• New users don't like controls
• Experienced users like controls
• Some settings are tweaked quite often, and should be easy to modify.
• All settings need to be tweakable somehow.
• Their should be a practical widget for every control.  (As an example where this failed:  Visual Studio 2005 let's you change the intermediate directory for C# projects only by editing the .csproj file in a text editor, and even then finding that you can do this is hard since the .csproj files and options aren't well documented.)

The requirements as listed suggest a hierarchy of options: one top level that is as simple as possible, and a sub layer where more controls are exposed.  However, then you run in to problems of how to display settings in the newbie top layer that have been tweaked in the advanced sub layer.  And there are problems with ensuring that both forms are in sync with the game data and each other.  Adding a new control requires modifying both forms, and you've effectively doubled the maintenance for GUI components.

Another option, as I mentioned, is to allow users to edit "advanced" features by editing the settings file as a text document.  But this always has the feel that what you're doing is back-door and sneaky, especially if the rest of the program is totally GUId.  As the case with Visual Studio demonstrates.

Also, the optimal solution, from a programmer's standpoint, needs to provide a zero-error way to add new controls and sync them with the game data.  This means one point in the code where all forms communicate with the settings structure, and one place where the settings communicate with the GUI.  Preferably the same place, and preferably it could be done automatically in some way.

So I don't know a good solution, but I'll keep thinking about it.

...Apple is very good at this.  Microsoft, not so much.

I guess I think like a developer.  I don't use many Apple products, but almost every program I use daily is Microsoft.  And I understand how the products I use work, and can tell you what almost every option or field does.