Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Carlo

Pages: [1] 2 3 ... 9
Quote from: Numsgil
Part of the problem is that the original installer sets up some VB runtimes that aren't always present on the target machine.  That's the main reason the old installer is still used at all.  It wasn't a huge issue, so I never put a lot of time in to it.  It probably isn't too difficult to set up some sort of installer or something.

try this:

Quote from: Numsgil
Honestly I could never figure out how you built the original download package.

Uhm, err... I can't remember exactly which tool I used, but it was a simple free tool for creating install packages. Anyway I don't think the install wizard is the main point here, just a zip file could be fine. The main point is giving the first coming user a collection of working dna files, example simulations, predefined settings, and docs, so that one can install and give a try at the program in a few minutes. If I was a first comer, installed the original exe, then patched it, and then found that the supplied bots aren't working, well, I'd probably have simply dragged everything to the trashbin.

Quote from: Seymour
Hi all, my first post here and hopefully not too annoyign for those who know whats going on.

Basically, I downloaded the program about 2 hours ago. I have a vauge idea now of how it works. However, the bots that come with the first instance of the program (version 2) are dated from around 2002. Having then updated the .exe (the zip didnt contain anything else) to the latest "official release" they seem to either not work at all or behave errtically. Which version do recommend I use for purely compatability reasons? (in other words, which version is best for simply importing species and watching- far too scared to put my own together)

Many thanks to whoever (anyone) answers my feeble call!
Peace love and robots,

C'mon, people, don't you think time has come for you to put together a stable, clearly documented package, with just the working species, example simulations, predefined settings of different environments, and so on? People gets scared when coming here, and it needs a lot of patience to download the original package, patch it, download the right species from the bestiary and set up the experiments without a single example file.

Suggestions / physics
« on: March 13, 2007, 10:58:55 AM »
Quote from: viplex
It occured to me while thinking about inceasing enviromental diversity: what do you think about splitting the screen in terms of physical properties, like gravity? For example, the upper half of screen would be earth gravity, the lower no gravity, like a pond and its surface. Viscosity, light and such things could also be adjusted this way. I think that would force lineages to diverge, while allowing some slow transfer.
However, I would be suprised hadnt this been already suggested or considered.

It's exactly the original environment grid idea, that is, to divide the field into small cells each one with its own values for physical constants (things like friction, gravity, etc.., but also costs). I think it would be, in itself, a great step towards evolution of diversity.

Biology / natural diversity VS simulated
« on: March 12, 2007, 01:57:06 PM »
Quote from: viplex
But in the sim, why do all species but one extinct? Time doesnt help. On the contrary..

It's an old problem. My opinion is that the enviornment DB offers is way too small and homogeneous to allow the existence of more than one species at a time. Simply, there isn't any reason for different species to share the same environment in a simulation; a few thousand cycles are always enough for evolution to tell the best one and make the others go extinct.
Real world is different because of specialization to different environments or different niches in the same environment. The complexity of real chemistry and physics allows numberless different niches to coexist in the same physical space. Spatial segregation, due to distances or natural barriers, is another source of diversity.

We discussed for a long time the opportunity to add complexity to the environment by superimposing to the field a so-called "environment grid". But there were different opinions about which properties of the field had had to be specified by the grid and nothing was done in the end.

DB Art / Blue Cotton Candy
« on: February 10, 2007, 07:33:42 AM »
Very nice. Looks like action painting - something like pollockbots, I'd say.

By the way, speaking of art, I like very much EricL's db-nonsense signatures   . EricL,  you should post them somewhere to preserve them from periodic changing.

Suggestions / Outsourcing physics
« on: November 04, 2006, 11:49:37 AM »
Hello everybody. Seems a great idea. My only doubt is that - as EricL suggested- common physics engines may be designed for handling with great accuracy the interactions of few, complex objects in a 3d space, while in DB the need is to make thousands of simple objects interact in a 2d space. Sound like the opposite, though I don't know if this is a problem. If it's not, I surely vote yes.

Suggestions / Sexual Reproduction Focus Group
« on: September 08, 2006, 09:47:54 AM »
Been playing with this on and off myself. I'll agree that's its way too easy to abuse the current system.

Some issues:

I've made species of bots that keep track of the other's sexrepro location then mate only if the other's nrg contributation is higher than their own. One bot will be giving 50% and the other a miserly 1%.
Well, you should think at it in an evolutionary way. If a bot can reproduce successfully giving only 1% of its energy, its genes will spread fast. And therefore it will soon be in competition with other bots which adopt the same strategy. Two bots adopting this strategy wouldn't be able to mate (each one is looking for the other having more energy) so that eventually being able to mate with everybody becomes an advantage again. Seems to produce an ESS (evolutionary stable strategy). Anyway, that's not an issue: observing this kind of effects is precisely what alife simulators are made for.
It would be nice to know the details of such a simulation. Can you tell us more about that? Maybe the graphs of the two populations, the "good guys" and the "higher than my own" guys? (Though probably there isn't a suitable tool for doing that in DB... something to watch for the spreading of a certain portion of dna in the population... good idea...)

Anyway, in real life thing seem to go pretty much this way. Everybody's looking for a partner which he considers to be at least as fit as himself... that's why we often fall in love with people who don't love us, and that's why, as years go on, we are content with something less

BotA: I'm willing to give X nrg
BotB: Well then, I'm willing to give Y nrg
Result: Both parents agree and a baby is formed
People seem to be much less sensible than that. You're way too optimistic about life

It's also possible to ensure all your genes are carried by another bot by simply doubling your geneome.
Ie. AAbbCCddEE (with each letter representing two identical genes)
This bot will always have 1/2 of it's genome carried into the child.
Yes, very important genes could be present in the dna in multiple copies to make the bots sure that they will be present also in the offspring; but having each one of your genes present in the offspring doesn't make the offspring more fit - if those genes arent' good genes. In other words: the only plausible effect is that very important genes are duplicated to ensure their presence in the offspring.

One last problem is the geneome size mismatch problem. A SG bot can take the majority of another's dna during sexrepro. Which explains these infernal plants we wind up with...
Obviously, the result of a mating between a veg and a non-veg has to be a non veg.

Suggestions / Sexual Reproduction Focus Group
« on: August 27, 2006, 08:03:23 AM »
A.  To bots that are mating under microscopic rules, sexual reproduction is really a fusing.  Two bots become one.  In such a system, the number in sexrepro doesn't really have a meaning.  Therefore I think that another variable should hold this information.  Leave .sexrepro to information such as relative amount of mixing, or something similar.  Something universal to the sexrepro process.

Sexrepro was originally desgned to give the effect of a macroscopic sexual reproduction, and the rules we defined in this discussion are referred to a macroscopic type of sexual reproduction. Fusing (making two cells become one, with the complete dna of both parents) could be an useful and interesting mechanism, but has very little to do with sexrepro as it has just been defined. So I can't see the point in using the same sysvar both for sexrepro and fusing (other than a nominalistic question). Let's just create another sysvar (.fuse, for example) which does the job.

B.  Imagine bots that, like worms, cross fertilize each other.  So both end up having babies.There should be a way of saying wether you're using repro nrg for your own kid or a kid the other bot makes.
Why? I can't see the point. The sexrepro takes place between two cells, not two worms. The offspring doesn't belong to one or the other worm, but in equal measure to both parents. By the way, it is interesting to figure out some different reproduction schemas for multicellulars. For example, org A and org B could touch each other with a reproductive cell, and the sexrepro would give birth to the embryonic cell of a new individual, while leaving the reproductive cells intact. Or the reproductive cells may invest all their energy in the offspring, disappearing after the mating. The cells may also be released in the environment like sperms or spores, or the mechanism may be asymmetric, with one organism sending its reproductive cell towards the other waiting for it.

The only danger I see is in two bots losing sight of each other and another bot swooping in and mating accidentally.  Losing sight of each other is very easy to do.  One of the bots could get hit by a flying veggy, or bounce against a wall.  It happens alot, even with bots that are designed to follow another bot.
I'd call it a technique for rape. Obviously sexrepro requires some additional care compared with the "typical darwinbots life" that is just going around almost carelessly and bouncing everywhere. It is possible that sexrepro will require an environment a little bit less competitive and in some way more sluggish, to allow bots to have more control of their movements and their relative positions.

I think it would make more sense to think of sexrepro as a request ("Will you have sex with me?") that must be repeated each cycle.  Like a mating call.  Sort of.
Well, that's just a matter of taste. Basically, the only difference will be in how much energy the bot will spend to maintain its sexrepro on.

I would connect only those bots who have contributed resources to the child. The child should be placed such that the distance from child's perimieter to both parents' perimiter is equal.  If there is only one contributing parent, the child should be placed as .repro kids are.
Both parents will contribute to the child. The least contribution possible is 1% of their own energy, but it will be very rare: if both bots contribute for the 1%, they will simply lose the energy (that given to the child and that necessary for the sexrepro command) and the child.

I think I can devise some sort of tree structure for keeping track of phylogenic trees.
That would be interesting, but not really necessary. It is sufficient for each bot to be recorded in the database with both parent's IDs to rebuild that tree completely when analyzing data.

My only point to point out is that maybe we should allow both line of sight and tieing, if for no other reason than that, should a bot couple wish to mate multiple times, the kid's going to get in the way! If the parents are still tied together, this problem is somewhat circumvented.
To have them both seems useless, and ties are a problem because of what has been said. Anyway, when sexrepro occurrs, a tie is created between parents, but keeping in sight is an ability bots should show to make more children. Id' just take care of children appearing in some point at the left or right of both parents, not in between.

I think this is reallt two questions.  Where and who.

As to where, the C++ base would make the most sense. It's certainly complete enough for all the features listed here, and it has the two benefits of STL vectors to handle DNA swapping (and keeping that swapping code clean) and a relatively well organized code base. On the other hand, since the code hasn't really been released to general use, let alone properly debugged, the implementation would be little more than proof of concept.
I haven't seen a working version of the c++ version yet, and if you can work on it just 2 days a week, probably it will take a long time before a usable version is released. The algorithm for swapping dna portions seems trivial in any language (except for the procedure to compare the dnas and find similar portions), and most of the other rules are in the already implemented sexrepro. So maybe you could write out the most difficult part, while others could make up the rest. Any volunteers?

Suggestions / Sexual Reproduction Focus Group
« on: August 26, 2006, 08:11:44 AM »
I think the currently implemented rules for sexrepro are almost ok.
This is the way I think sexrepro should be implemented now:

1) Sexual reproduction can be performed by two normal bots through the use of the .sexrepro location, and results in the creation of children bots with a "good mix" (more on this later) of the dnas of the parents.
2) The partner for the mating has to be clearly identified: this is achieved by having bots looking each other.
3) The mating should be generally consensual: both bots should have their sexrepro location activated.
3.1) The .sexrepro location value should express the percentage of his own energy each bot would give to the child. This is particularly interesting because gives birth to a prisoner's dilemma game.
3.2) The .sexrepro location is not reset until a mating occurs (this makes easier to mate if no selection of the partner is made).
4) The mating bots should be in proximity of each other (no "action at a distance").
5) A bot may be involved in only one mating per cycle.
6) After the mating, parents and child are temporarily connected through a reproduction tie (for similarity with asexual repro).

and finally

7) The program should keep track of two parents, recording their IDs
8) The generation value should be discarded when sexrepro is used or substituted by an approx value like (gen par1+gen par2)/2+1 or whatever else

Ok. During the discussion we agreed on the fact that the current way of creating a "good mix" of the dnas of the two parents isn't good at all -it is flawed and, besides, it is gene centric. But Numsgil said he can implement a much more sophisticated dna mixing system, so this should be no problem.

Another point we should consider is how many children should be generated in a mating operation. As the operation of finding a partner is expensive in terms of time and energy, we may decide to allow the creation by the couple of many children at once. The only problem is to decide _how_ the bots may decide to create more children.  One possible solution is to allow robots to mate repeatedly with the same partner while the first mating operation isn't yet complete (that is, while the two parents and the children are still connected by reproduction ties); but we don't even have to explicitly allow it if we don't state that two bots can't mate until one of them is still in a mating operation with a third one. So, either we add two rules (robots can't mate until a previous mating is ended BUT they can do it with the same partner) or we simply let bots mate at every time (which is my preferred, I'm for deregulation).

So do we want to acchieve partner selection through:
 - Ties?
 - Line of sight?
 - Shots?
 - Proximity/Physical contact?
Couples of bots must be identified by a link of some form connecting them. Shots and proximity won't work since the first are difficult to use and synchronize, and the second is not a 1 to 1 relation. Line of sight and ties would be both ok, but surely the easiest way to identify with precision a couple is to have them looking at each other: it links the two bots, but at the same time leaves them completely free. A tie links two bots, but also has the annoying physical effect of keeping them together. If you consider that the linking operation should take place before bots express their consent to sexual reproduction, you can imagine what a mess would be having horny bots going around linking everybody.

So, who's gonna implement this?

Suggestions / Sexual Reproduction Focus Group
« on: August 25, 2006, 06:41:05 AM »
When a bot no longer sees any bot, the .lastopp (the bot it saw last) variable isn't reset.  Let's say that the bot it wanted to mate with managed to die before it could mate.  The other bot will still be pining away for bot #21, whose slot happends to be empty.  Since sexrepro isn't reset, it will keep trying to mate with bot #21.  Eventually, slot #21 will be filled again, and should that new bot be attempting to mate too, and happen to be relatively close, the bot will end up mating with that bot.

Just a little bug. Very unlikely to happen, but, to fix it, you can just add to the internal value of lastopp the unique id of the seen bot. And before doing anything with the lastopp value, you should check that the bot in the array slot has the correct unique id. The lastopp stores the array slot instead of the unique id just for speed purposes.

Likewise, it's possible that if bot A and B are mating, bot C could look at bot A and mate with it.  Or it could be that they form a threesome, with bot A taking DNA from bot B, who takes DNA from bot C who takes DNA from bot A.  Theres no code to deactivate a parent's sexrepro once another bot decides to mate with it until a child is formed, which means its possible a bot could find itself the parent of 5 or 6 children when it only mated once.

Isn't necessary for bots to be both looking at each other in order to mate? And the .sexrepro value should be set to zero once a mating took place. If bot 1 mates with bot 3, bot 2 can't mate with 1 in the same cycle, since when the procedure examines bot 2, bot's 1 sexrepro has been set to zero (it may be that the code actually sets to zero the sexrepro after examining ALL the matings, but then we can just modify a little the code. By the way, yes, having a low slot in the bots array actually has some advantages, but since the slot is  chosen randomly, those advantages are equally distributed among all species).

(parents and generation tracking are) Minor problems yes, but problems that should be addressed, especially if you want to study the ancestry of a bot (which would be important for studying group genetic drift, or something similar).

Problems that would become even worse if we introduce diploidy, genes sharing, etc. So, they can't make you look for such kinds of alternatives. Anyway, a serious study of the simulation can be made ONLY through the database recordings, which should just record two parents instead of one to let you keep track of the complete genealogic tree. So, the only thing to do here is duplicating the parent field in the robot's data and record it in the database file. As for the generation data, we can give an indicative value like the mean of the parent's generations + 1 or something like that.


Suggestions / Sexual Reproduction Focus Group
« on: August 12, 2006, 08:51:19 AM »
Anyway, I'm leavin' for holidays. Will be back in a week or so.
Good bye!

Suggestions / Sexual Reproduction Focus Group
« on: August 12, 2006, 06:18:09 AM »
0.  Sex is performed between two bots.  The first bot is the one that initiated the sexual reproduction.  The next bot is the bot that's next in the reproduction array.  Who's next in the reproduction array?  The last bot that the initiating bot saw in eye5.  If this other bot is not sexually reproducing, sexrepro shouldn't occur.
1.  Both bots' centers must be within 2 robsizes of each other.  ie: they basically have to be within 1 robot length of touching.
This makes sense. Not only they have to physically near, they also have to be watching each other. Romantic, isn't it? This allows a bot to know exactly who is he mating with, even if there are other bots around.

2.  Both bots DO NOT have to be sexreproing at the same time.  sexrepro isn't cleared every cycle.  It's only cleared if the bot successfully sexrepros.  Thus an unwary bot could find itself forced to reproduce and contribute all of its energy to an offspring.  This could be used as a weapon.
This give bots more control. If they want, they CAN clear sexrepro at every cycle. It's a matter of choice.

3.  Properties are determined by how much each parent contributed during sex.  It handles poorly things like species lineage, generation, robot color, and other properties that would probably make more sense by remembering both parents.  This basically means that any person trying to figure out what's going on in their sexrepro sim is going to be very confused.
This isn't a problem of the simulation in itself, but of its framework. Simply, DarwinBots wasn't designed to keep track of two parents per reproduction. Same for generation, the very concept can't apply to a sexual reproduction. Robot colors can be mixed, or inherited randomly, but hey, who cares? Anyway, minor problems here.

4.  The parents' DNA is shuffled every other gene.  That means 1st gene comes from mom, second from dad, third from mom, fourth from dad, etc.  Any leftover DNA (one parent has more genes than another) is either slapped on the end of the child or not (depending on a 50/50)
This is the worst thing in sexrepro. It works as long as there aren't gene duplications or deletions, otherwise it is likely to shuffle off the genome some important gene shared by both robots. It should be substitued by an algorithm lining up similar genes in groups and then taking approximately half of the copies per group.

The problem with the original sexrepro:

1.  Selection of mates is too limited.  Sexual reproduction needs to be a mostly consensual.  You need to be sure exactly who you're mating with.
You can, if you take care of your .sexrepro. And the lesson is: if you give it around to everybody, you can't blame society for being a teen mother.

3.  The code was gene-centric.  Post 2.4, the only gene centric DNA commands relate to viruses.  The gene structure is just too impossibly complex to do this anymore in a meaningful way.  Also simply lining up genes and picking one from either one DNA or the other won't work effectively when you begin to consider large insertions, deletions, and reversals (mutation types that do not cause catastrophic failure in real organisms).  If a bot is missing gene 2 you would hope that genes 3, 4, and 5 would still cross over effectively.  You hope that gene 2 might even be replaced by a sexual encounter.  This isn't possible if you just mindlessly shuffle the 1st genes followed by the second genes, etc.
Well, the whole DarwinBots was gene-centric when I added sexrepro, and (to be honest) I don't even know what the actual dnas look like (or could look like). If genes aren't well separated anymore, then things get more complex. But the basic point should be the same: grouping similar sequences and then choosing randomly which to use in the new dna.

4.  Fails to model any but the macroscopic version of sex.  By which I mean a mother and a father copulating to produce a new unique organism. As opposed to microscopic sex that involves two organisms fusing, their haploid DNA becoming diploid.  Both should evidently be very different.
That's a different problem. There are many things the actual repro and sexrepro fail to model, being high level commands that just fire an automated process. But until we focus on organisms behaviour and leave out the details, I don't think that there's any need to model low level sexual haploidy and diploidy. Bots are well defined individuals, like sheep or ants, so they aren't expected to fuse, but to mate.

The following is no longer necessarily fact, but is my own personal opinion:
Crossing Over:
The best solution is to line up the DNA based on similar sequences instead of similar positions.  You then "twist" the strands in a few random places to shuffle it a bit.  Very simple swapping.

This is not complicated.  It is in fact ingeniously simple when you consider the number of programatic hurdles to overcome.  Any complication people percieve is entirely in their minds.  It is in no way more complicated than "swap every other gene", or something similar.
I'd start with this, which fixes the actual working of sexrepro without any major change at high level. Then you can add whatever you want, but before making great plans, I'd just fix what's broken.

Suggestions / Sexual Reproduction Focus Group
« on: August 11, 2006, 12:32:10 PM »
Quote from: Griz
why does a bot have to choose?
Because one of the most important mechanisms of natural selection is called sexual selection. Animals tend to evolve features which can increase the probability of being chosen by a partner for reproduction, even if those features are useless or noxious in everyday's life. The usual example of the results of sexual selection is the peacock's tail, but the examples are countless. It is common opinion that sexual selection may have played a major role in the evolution of the human brain itself, favouring language and other kinds of abilities (musical, for example) much beyond the real needs of the species.

A great artificial life simulator designed to play with sexual selection is Ventrella's Darwin Pond.

(though I'm sure that everybody here knows it already    )

Suggestions / Sexual Reproduction Focus Group
« on: August 11, 2006, 11:48:17 AM »
Quote from: Elite
Actually, after some experimentation in 2.37.6 with a .sexrepro-using Animal Minimalis, it doesn't seem that bad at first glance. Slightly buggy in some areas (ie. no reproduction collision detection) but not that bad

What do you mean precisely with "reproduction collision"?

My first worry was that the sexreproing bot would combine with a veg or an entirely different bot, but the code seems to prohibit sexual reproduction if the genomes are two dissimilar

Hm, no. The code shoudn't prohibit nothing but, as one would expect, if the dnas are too different the reproduction fails - the child isn't able to do anything and dies rapidly.

My only concern is that, as PY said, there's no way to choose your 'mate' - you just get your DNA yanked out of you if you're nearest

Well, ideally the bots should activate their .sexrepro locations just when they've found a good partner and are in contact with it. Activating it and then keeping roaming waiting for a random collision is just the simplest way to reproduce - not the best one. Also, if I'm not wrong, the procedure requires both the bots have their .sexrepro activated, so the collision should be with one who is also willing to reproduce.

How about having .sexrepro fire a tie forward, which, on hiting another bot, takes that bot's DNA and mixes it with the original bot in a manner similar to the original .sexrepro

(Original sexrepro? What sexrepro are we talking about?) . Anyway, the tie isn't a bad idea. By the way, maybe glue would be even better. Has anybody thought of a glue which makes robots stick together without being actually tied, that is, something that just keeps two robots attached until a slight force divides them?

That way you can choose your mate by hunting round, say for a bot with more than a certain energy or kills (ie. allows for sexual selection), and then aquiring it's DNA through a sex-tie

I'd like better a simmetric process, in which both bots are willing to mate and the offspring just belongs in the same way to both partners.

Pages: [1] 2 3 ... 9