Darwinbots Forum

Bots and Simulations => Simulation Emporium => Topic started by: Testlund on October 23, 2005, 12:07:10 PM

Title: Firecracker behavior
Post by: Testlund on October 23, 2005, 12:07:10 PM
Either this is a bug or some bots develop high speed metabolism.
Title: Firecracker behavior
Post by: Griz on October 23, 2005, 12:49:20 PM
have you tried zipping the sim and seeing if it is small enough to upload here?
if a version that has the user able to set the seed ... that would be good to know too.
I have observed this as well ... but have no idea if it is normal/intended ... or not.
Title: Firecracker behavior
Post by: Testlund on October 23, 2005, 01:12:42 PM
This behavior seems to happen in all my simulations.

I don't think it's any point to send saved simulation just yet. I don't know about you but I can't load them, only save them.
Title: Firecracker behavior
Post by: Testlund on October 23, 2005, 01:25:27 PM
Hmm. I tried to upload but the file is too big.
Title: Firecracker behavior
Post by: Griz on October 23, 2005, 02:06:51 PM
even after zipping?
I haven't tried it yet ...
although I imagine your sims will be large ...
as you run a very large field and many bots.
maybe start the sim as new ... and immediately save it before the pop goes up.
anyway ...
have fun. ;)
Title: Firecracker behavior
Post by: Numsgil on October 23, 2005, 02:47:32 PM
Are the "fireworks" from the bots dying or are they shooting?  I'm not sure exactly what you're trying to say...
Title: Firecracker behavior
Post by: Old Henk on October 23, 2005, 02:48:38 PM
Beware! Those cells have become cancerous!  ;)
Title: Firecracker behavior
Post by: Testlund on October 23, 2005, 03:01:24 PM
Well... The mother cell copy itself into 1 or several cells wich immediately copy themselves and then they all explodes, everything happens very quickly. Could be cancerous, but not in the way real cancer cells behave. In the real world cancer cells keep on living.
Title: Firecracker behavior
Post by: Numsgil on October 23, 2005, 03:09:58 PM
It's actually rather common to have bots evolve to always reproduce.  They usually go poff-poff-poff for a while, then exhaust themselves and die.

Except veggies, which, under the right conditions, can totally take over the whole sim when they turn cancerous.
Title: Firecracker behavior
Post by: Testlund on October 23, 2005, 03:19:17 PM
Maybe that sometimes happens in nature too, but it seems useless. I think it happens too often in this program though.

Another crazy thing is when a bot keeps producing offspring wich it immediately consumes, like it's recycling the energy. That doesn't exist in real world, right? Of course canibalism exists but not like this.

Could you make the program behave within Mother Nature's rules?
Pretty please!  :P
Title: Firecracker behavior
Post by: Numsgil on October 23, 2005, 03:33:48 PM
Define a rule set that would fix these problems.

There isn't anything stopping a mother and child from physically eating each other.  There are some insects, etc. that will eat their young.  If a bot is stupid enough to eat its babies, who are we to say it can't?

Likewise with reproducing non stop.

If it's a bad behavior, it will die out.  If it's a good behavior, it'll stick around.

Chweck out Enitor Comesum (or is it comesum enitor...) in the beastiary.  It's a cannibot where the children have to fight their parents and siblings since their first waking moment.
Title: Firecracker behavior
Post by: PurpleYouko on October 23, 2005, 04:05:11 PM
Why not use the scripts to help prevent it.
Title: Firecracker behavior
Post by: Griz on October 23, 2005, 04:49:19 PM
Quote
Why not use the scripts to help prevent it.
ah! scripts.
how? and what scripts can be used to do what?
some examples?

another question:
could one design a particular bot ...
put an instruction in the DNA ...
to have it die off after a certain age?
and if so ... could this be made a variable?
something that could be altered from the program, a setting or script?
Title: Firecracker behavior
Post by: Numsgil on October 23, 2005, 05:12:46 PM
You can insert such a thing into the bots' DNA, but it will probably quickly evolve to break it.  Evolution is really good at breaking certain parts of the DNA, it's among the first things it "tries".

Scripts I haven't much played with to be honest, they're primarily PY's baby.
Title: Firecracker behavior
Post by: Endy on October 24, 2005, 02:50:57 AM
Quote
You can insert such a thing into the bots' DNA, but it will probably quickly evolve to break it. Evolution is really good at breaking certain parts of the DNA, it's among the first things it "tries".

Sure, it's only logical. For further evolution the bots have to break any restrictions.  More or less the bots are asexual so one bot's evolution has to occur at the expense of all others. One bot will break it first and then replace/destroy the others that have the restrictive genes. The same thing is commonly seen with Canni's.

I normally just use restricive or specific genes with the knowledge that evolution will come along and break them in sucessive generations. Normally something like:
Code: [Select]
'Last Gene
cond
*.robage 10000 >
start
.delgene inc
stop

works best. I've deliberatly tried restricting mutations with a dnalen restriction, and evolution still wins out. :)

They really like using the new flip mutation to do break them for some reason. I think it makes it easier, since it is more likely to affect more dna.

I don't know if we should call such behavior cancerous, technically the vegs are just playing the system. Evolution is "telling" them that the cost of attempting to reproduce is les than the penalties.

Basically the vegs are restricted by veggie population size and total veggie nrg. Since they can expand their total population size by continually reproducing it's better if they do. Increasing the total size decreases the chance of any specific vegie from being eaten. If they're being eaten this depletes total nrg and is again a good time to try and reproduce.
Title: Firecracker behavior
Post by: Numsgil on October 24, 2005, 09:47:02 AM
If you switch to nrg per kilobody, this nasty little problem goes away entirely.

Of course, the veggies don't really evolve in such an environment because they just get eaten.  Thems the breaks I guess ;)
Title: Firecracker behavior
Post by: PurpleYouko on October 24, 2005, 09:53:03 AM
Quote
ah! scripts.
how? and what scripts can be used to do what?
some examples?

At the moment scripts are designed to work solely at the reproduction stage and only on the young bot.

The kind of thing you can do is to set it up such that if a bot evolves a certain DNA command (or loses one) then that bot can be punished (by immediate death) or highlighted or paused or even have a snapshot taken.

It is still a bit limited in scope but will be expanded on at some point to include population controls, age limits, kill counts and many others
Title: Firecracker behavior
Post by: Numsgil on October 24, 2005, 09:55:07 AM
And may not work properly in 2.4, I keep forgetting to check and see.
Title: Firecracker behavior
Post by: Griz on October 24, 2005, 10:36:47 AM
Quote
Basically the vegs are restricted by veggie population size and total veggie nrg.
I would agree ... however ...
max veggie number doesn't work in the new versions. ;)
so once again ...
the existing bugs should be fixed BEFORE introducing more flash stuff
and the resulting bugs/problems that come with them.
the priority should be to make a version that WORKS as advertised!
that should be the primary focus ...
fix what you got ...
and then ...
move on to introduce 'improvements'  ...
as they then may actually turn out to be ... improvements.

take a look at real life ... (anyone remember that) ;)
what works continues ...
and what doesn't ends.
what does survive is retained ...
offspring versions are tweaked slightly and added
to the pool ... to the population and then tested.
key words ... added & tested.
the new does not displace what has worked before until/unless
they prove to actually be competent to do so ...
as tested by the environment ... by life.
and the process of evolution continues.

I suggest we might consider following the same formula ...
when it comes to program development.
Title: Firecracker behavior
Post by: PurpleYouko on October 24, 2005, 11:33:22 AM
Quote
I suggest we might consider following the same formula ...
when it comes to program development.

I have always tried to follow that formula. The problem is that adding one seamingly simple little thing tends to end up screwing up something else in an utterly unrelated area of the code.

Here is an example that happened a while back.

I decided to add corpes. Seemed like a real cool idea at the time. Should be easy and all that.
I added them and it was easy. Tested them to death (excuse the pun) using Hunter 2.3 (about the most advanced shot bot of that era). All worked great. Couldn't make it fail no matter what I did.

I released the version and all hell broke loose. It seems that a whole bunch of more primitive bots kept exploding after giving birth and MBs all over the place started dying when they shared energy.

The problem?

In order to make a bot become a corse while it still has some meat on it, it was necessary to introduce a couple of new rules regarding what actually kills a bot. It turned out that when a gave lost more than half its total energy in one go, it just up and died. Unfortunately this happens all the time during reproduction and energy sharing.
I had to go back and patch the software with escape clauses to get away from the instant death scenario.

Changing stuff in a program this complex is a nightmare.
Title: Firecracker behavior
Post by: Griz on October 24, 2005, 11:52:25 AM
this is why it is important to limit the amount of change we make at any one time.
and then to not cast aside what went before ...
until we can be certain that we have actually made an improvement.
what I see going on here now is ...
change upon change upon change upon change ...
and never going back to fix what gets broken before making more.

I think we can all see this happening.

I'm only asking for a stable working platform ...
that I can actually use as an evo sim ...
and then I have no problem with anyone forging ahead to bigger
and better things .... wonderful .... more power to you all.

that's all.
Title: Firecracker behavior
Post by: PurpleYouko on October 24, 2005, 12:22:48 PM
Yes I tend to agree with you there Griz.

You have to understand though that adding new stuff is downright fun while debugging old (and often not your own) code is extremely frustrating, annoying and downright boring.

That isn't intended as an excuse but is the unfortunate reality. I spent literally months debugging Carlo's original 2.11 to make it work properly. Every bug I fixed just unleashed a torrent of new ones.

It can be a bit soul destroying after a while.

I think the best thing to do for now is to keep the 2.37 version for debugging in order to get a nice stable platform. I will undertake that nasty little job when I get time.

Num can continue developing and debugging 2.4

Eventually we should be able to recombine the two versions but for now they probably need to be developed in parallel.
Title: Firecracker behavior
Post by: Numsgil on October 24, 2005, 12:39:00 PM
I'll admit I have a poor habit of entirely commenting out old code I don't understand and writing my own.  Bad Numsgil, bad  :pokey:

I am constantly making the code alot more readable.  This alone has caused entire thousand line modules to be completely rewritten.  Bugs are bound to crop up.

As for a stable version, if you turn autosave on, and the sim crashes, you can just boot up your most recent autosave.  Longer simulations are quite possible, bugs do not mean the end of a week's worth of effort.

Oh, and veggy population controls are indeed working as well as they ever did.  But you have to understand how that is...

at the beginning of a cycle, all the vegs are counted up.
at the end of the cycle, if the total vegs coutned at the beginning is less than the pop limit, all vegs are allowed to repopulate.

Mmm, yes, you see the problem now?

So the pop limit you see in the options panel is actually half of the maximum population you should ever expect to see.
Title: Firecracker behavior
Post by: Griz on October 24, 2005, 12:48:33 PM
Quote
Mmm, yes, you see the problem now?
seems to me that cyclying between 790 and 490 ...
is a bit lager than the max 25 I had set. ;)
in any of the 2.4x series ...
the max cap has never held down the population. not ever.
this is my experience ... and I played with this alot in 2.36 and 2.37
to get a handle on how it worked there.
Title: Firecracker behavior
Post by: PurpleYouko on October 24, 2005, 01:01:26 PM
Always worked perfectly for me but then I still run 2.36.7 mostly.
Title: Firecracker behavior
Post by: Numsgil on October 24, 2005, 01:48:29 PM
I didn't touch that code...   :unsure:

Um, I guess I'll go check it out.