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.


Topics - cliftut

Pages: [1]
1
Suggestions / Graphs not always on top?
« on: August 06, 2007, 08:31:25 PM »
The graphs are always on top of all windows even if I minimize DarwinBots. This is a bit frustrating because I've been trying to run evo-sims while I browsed the forums, but I'd have to minimize all 2-3 graph windows and then maximize them again when I wanted to chech the sim. I suggest that all sub-windows governed by DB automatically minimize when the main window is minimized, and that the always-on-top behavior of the graph windows, and perhaps option windows as well, be changed. Hey, why not also make it so that they don't take up space on the Task bar anymore? Well... actually, you can scratch that one if you want... I think I'm starting to sound whiney.

2
Suggestions / new graph type
« on: August 06, 2007, 08:09:02 PM »
I know I'm making another suggestion rather soon. I tend to get hit with ideas in rapid succession.

Out of the graphs you can bring up in game, the two I find most useful are the avg. mutations graph and the populations graph (the avg. dna length fascinates me, but having too many graphs covers up the sim and annoys me). I think there are possibilities for new graphs that could be useful. I've thought of one so far.

Strains Graph
When a bot mutates, it becomes another strain within the bot species. A graph that shows how many strains of each species are in the simulation could be useful to show areas of transition. When the number of stains remained above 1 for a relatively long amount of time, it would probably be because the mutations that created the new strains did not cause a major advantage or disadvantage for it. however if the strains dropped back down rather quickly, it would probably because the new strain either won out or died out. You would be able to tell which by seeing if the avg. mutations graph went up or down. If up, then the new strain won out. If down, then the old one won.

This could be useful for more accurately tracing what exactly evolution is doing, and I don't think it would be to difficult to add in.

3
Suggestions / New feeding methods
« on: August 06, 2007, 07:27:50 PM »
I had this idea the other day. As far as I know, the feeding methods in DB don't really resemble real life feeding methods. This caused me to think about how actual single-celled organisms feed. There are two main ways that I know of; some larger ones do so by "taking in" smaller organisms, and some smaller ones "hijack" larger organisms by penetrating into them and using them as a breeding house. I was wondering if these sorts of behaviors could be implemented in DB.

-------
[you]
1. Engulfing other bots
[/you]
A bot would only be capable of absorbing a bot smaller than it (less mass), and it could only engulf multiple bots if their mass equalled less than its own. A bot would engulf another bot by throwing out a special type of tie that would drag the other bot inside of them (this tie, although invisible, would remain connected even when the bots were inside). Once a bot was inside, the bot that engulfed it would expand as their masses were added together (if multiple bots were engulfed, the bot that engulfed them would expand by adding all of their masses to its own. Also, if "fixed bot radius" was checked in the options, the bot would simply enlargen to acommodate the bots it absorbed). Any bots pulled inside would act as if they were tied to the bot that engulfed them (but not to each other). Energy sharing, waste sharing, tie feeding, or memory editing could be done by the bots to the one that engulfed them, or to the engulfed bots through this "virtual internal tie". Naturally, tie lengths and such things would not apply, though, so trying to changer them would have no effect. Any nrg, poison, venom, waste, or virus shots fired a bot that was engulfed would act as if it had hit the bot that they were inside (feeding or body shots would be disallowed). Also, the bot that engulfed another bot could transfer its own poisons, venoms, or virii to the engulfed bot/s. The movement of any absorbed bots would be prohibited. If the bot that had engulfed the others died while they were still alive inside, they would be released. I'm not sure if engulfed bots should be allowed to reproduce while inside.

To feed off of engulfed bots, the bot would either "decompose" them (feed nrg from them while randomly deleting their dna; this could be automatic or require a special sysvar command), or tie feed from them using the "virtual internal tie". The main pros and cons of this feeding method would be as follows;
PROS:
   1. It would be efficient like tie feeding; no worry of feeding shots missing or nrg shots not being collected.
   2. It would not hinder a bot's movement like tie feeding does.
CONS:
   1. Since the mass of any absorbed bots would be added to the mass of the one that absorbed them, it would become larger and easier to hit.
   2. The bot that engulfed the other bot/s would inherit all of their waste as it absorbed them, since they would be inside of it.
   3. Any bots that were absorbed could easily affect the bot that had engulfed them with poison, venom, or virii. They could also drain nrg from it, but that would have to a specialized response, taking advantage of the "Virtual internal tie".

I think that this would allow for some interesting behaviors in bots, and since a bot that engulfs other bots doesn't have to feed off of them, two bots could have a symbiotic relationship, where one lives inside another.

--------
[you]
2. Infecting (Hijacking) other bots.
[/you]
This would be the reverse of the above. A bot would only be able to do this if it was smaller than half the mass of the bot it hijacked. Similarly to engulfing, the smaller bot would shoot out a tie to the larger one, and pull itself inside the larger one, and adding its mass to the larger one's (like with engulfing, this tie would remain connected even once the bot was inside). Once inside, any shots it fired (except for feeding and body shots) would act as if they automatically hit the hijacked bot (the host). The bots would be capable of reproducing while inside the host bot, as well as feeding energy from it. If the mass of the bot/s inside exceeds the mass of the host bot, then the host would die. When the host bot died, the hijackers would be released. They would also be able to escape on their own by using a special command. The pros and cons of this method are as follows;
PROS:
   1. While inside a host, the hijacking bots would be safe from direct attack.
   2. The bots would not be able to harm one another while inside their host.
   3. They could easily use venom, poison, or spread virii to the host.
   4. They would only inherit a fraction of the host's waste when they fed off of it, unlike with engulfing.
CONS:
   1. They would be incapable of movement while inside the host; they'd go where the host went.
   2. I'm sure there would be other disadvantages, but I can't think of any others right now.

---------

Does anyone think that these would be good for DB? They are fairly flexible, allowing for feeding or symbiotism, not to mention they mimic real life a bit more than the current feeding methods. Some interesting ideas come to mind. One of which is a bot that would engulf veggies and use them as batteries.

Also, these would allow programmers to produce unique multibots (I'm sure they would count as multibots if they were designed right).

I realize these would probably be tough to implement, but that's just me guessing. I think they might be worth some effort to introduce, though.

What do you think? This post is really long... >< I've attached an image because I get nervous about my ability to explain things when my paragraphs get too long...

4
Bot Tavern / Evolved tie-bot...
« on: August 04, 2007, 10:47:25 PM »
This bot evolved from the 2.1 version of T_Preservans. Whilst entangled in a fight versus some evolving veggies, This lucky guy happened to gain the ability to throw ties (it tends to favor tieing it's buddies). I'll attach a simfile so that you people can see what it does.

I've found that the seemingly ideal environment for this bot is one in which the veggies aren't fixed. This means that grabbing the veggies via ties makes them easier to hit.

There are some problems with this behavior, so even in the sim I designed for them they tend to drop the tieing ability after a while. I'll list them;
1. When they tie to other bots they fight, trying to pull in different directions. Useless spinning motions and chaotic motion result, making it difficult to feed.
2. Once they are tied to a veggie, they tend to end up facing away from the veggie, making their constant shots useless until either a link is broken, or it links to other veggies/bots causing it to change orientation.
3. They end up cannibotting by accident because their ties force them to face one another. When too many bots get linked together (this often happens when feeding, because the children tend to get netted by their parents or other nearby bots, putting them or their parents in the line of fire)
4. Overall free swimming non-tying bots seem superior, so evolution tends to work against the tieing until it disappears from the genome.

There are some good points, though.
1. Once enough veggies have been netted, the bots can feast and multiply quickly.
2. If a more efficient feeding method was introduced, a bot that netted its food could have an advantage since the veggies are free-floating.


I would like to see if any interesting behaviors can be evolved from this. If any of you could run the sim for yourself or experiment with it yourself, I'd be grateful. I would be very happy if anyone could suggest settings that would encourage further development of this tying behavior.

Also, is there any way to make the code more readably besides going through it manually? I'm a newbie, so I don't understand the code enough to tell what's doing something and whats not.  I heard someone mention a script that would remove all the junk code created by evolution, leaving only the functional parts. Anyone know anything about this?

Here is the code for the bot.
attached is a simulation file containing "Connectus Preservans" with free floating veggies and one with fixed veggies.

The way it attacks fixed veggies is interesting. If one of the bots manages to get enough energy from a veggie to reproduce, it usually ends up with both bots linked to each other and to the veggies. They continue to feed, wiping out the veggie patch they have attached to and rapidly reproducing, creating a large net of bots that completely engulfs the veggie patch, devouring it. Once the patch is gone, usually the bots start killing each other because they are so close together and all linked. The result is that the bots kill each other off until all that is left of that group are a few bots, usually tied together and circling pointlessly until one or two more die off. It's very interesting... I might make a video of it for those who don't want to test it themselves (or read all of this ;;).

Sorry for my rambling, but this interested me... if anyone else cares enough, feel free to ramble some yourself!

5
Mutations / Connecto_Preservans
« on: August 04, 2007, 03:39:36 PM »
There are two things that you must realize about this bot.
1. this is the result of a while of evolution. The strain that developed linking (this bot) died off very shortly because linking to other bots got it shot up. Simply put, it is not an optimal bot.
2. THIS BOT WAS EVOLVED IN DB VERSION 2.1! I was messing around with the default bots in 2.1 to check them out, and this bot happened to show up in a fight between T_Preservans and mutating veggies. To see what the bot was really like, run it in version 2.1. I have not tested it much in 2.43 since I'm just now starting to use it. I'm pretty sure it works similarly in 2.43, though.

Here's the bot;
Code: [Select]
cond
  *.refdn
  20
  >
start
  4
  *40
  add
  .tie
  store
stop

cond
  *.eye5
  0
  =
start
  1
  *40
  add
  40
  store
stop

cond
  *.refdn
  20
  >
start
  100
  .aimdx
  store
stop

cond
  *40
  200
  >
start
  1
  40
  store
stop

cond
  *.eye1
  0
  >
  *.refdn
  20
  <
  *.eye5
  0
  =
start
  59
  .aimsx
  store
stop

cond
  *.eye2
  0
  >
  *.refdn
  20
  <
  *.eye5
  0
  =
start
  46
  .aimsx
  store
stop

cond
  *.eye3
  0
  >
  *.refdn
  20
  <
  *.eye5
  0
  =
start
  31
  .aimsx
  store
stop

cond
  *.eye4
  0
  >
  *.refdn
  20
  <
  *.eye5
  0
  =
start
  16
  .aimsx
  store
stop

cond
  *.eye5
  0
  >
  *.eye5
  50
  <
  *.in1
  20
  <
start
  5
  .up
  store
  add
stop

cond
  *.eye5
  49
  >
  *.refdn
  20
  <
  *.refnrg
  500
  >
  *.refshoot
  0
  =
start
  2
  .shoot
  store
stop

cond
  *.eye5
  49
  >
  *.refdn
  20
  <
  *.refshoot
  0
  >
start
  2
  .shoot
  store
  5000
  .shootval
  store
stop

cond
  *.eye5
  49
  >
  *.refdn
  20
  <
  *.refnrg
  500
  <
  *.nrg
  500
  <
  *.refshoot
  0
  =
start
stop

cond
start
 -1
  .shoot
  store
stop

cond
  *.eye5
  49
  >
  *.refdn
  20
  <
  *.refnrg
  500
  <
  *.nrg
  499
  >
start
  200
  .aimdx
  store
  div
stop

cond
  *.eye6
 -4
  >
  *.refdn
  20
  <
  *.eye5
  0
  =
start
  15
  .aimdx
  store
stop

cond
  *.eye7
  0
  >
  *.refdn
  20
  <
  *.eye5
  0
  =
start
  30
  .aimdx
  store
stop

cond
  *.eye8
  0
  >
  *.refdn
  20
  <
  *.eye5
  0
  =
start
  45
  .aimdx
  store
stop

cond
  *.eye9
  0
  >
  *.refdn
  20
  <
  *.eye5
  0
  =
start
  60
  .aimdx
  store
stop

cond
  *.eye1
  0
  <
  *.eye2
  0
  =
  *.eye3
  0
  =
  *.eye4
  0
  =
  *.eye5
  0
  =
  *.eye7
  0
  =
  *40
  100
  <
start
  .dx
  store
  40
  store
  5
  .aimdx
  store
stop

cond
  *.eye1
  0
  =
  *.aimdx
  0
  =
  *.eye3
  0
  =
  *.eye4
  0
  =
  *.eye5
  0
  =
  *.eye7
  0
  !%=
  *.eye8
  0
  =
  *.eye9
  0
  =
  *40
  100
  >
start
  4
  .up
  store
  5
  .aimsx
  store
stop

cond
  *.nrg
  10000
  >
start
  400
  .aimdx
  store
  sub
  20
  .repro
  store
stop

cond
  1
  0
  =
start
  0
  .dn
  store
  0
  .dn
  store
  0
  .dn
  store
  0
  store
  0
  .dn
  store
  0
  .dn
  store
  0
  .dn
  store
  0
  .dn
  store
  0
  .dn
  store
  0
  .dn
  store
  0
  .dn
  store
  0
  .dn
  store
  0
  .dn
  store
  0
  .dn
  store
  0
  .dn
  store
 -4
  .dn
  store
  0
  .dn
  store
  0
  2
  0
  .dn
  store
  0
  .dn
  store
  0
  .dn
  store
  0
  .dn
  store
  rnd
  0
  .dn
  store
stop
end

6
Newbie / Upgrading the default (2.1) install
« on: August 03, 2007, 12:47:43 AM »
Alright. I got DB 2.1 and tried to follow the instructions to upgrade to the latest version. I unzipped the files for 2.43 into the main DB directory, only to discover that the only thing that was in the 2.43 zip was an .exe. I had read something about "sysvars.txt" being overwritten in this process, but all that happened was that the DB 2.43 executable was added to the folder.

I ran it and it opened fine, but it says that none of the default simulations are compatible with this version. This was a little discouraging, so I've been ignoring the new .exe and using 2.1 to just test out the bots and sims that come with it. I'm one of those types that likes to test out the default stuff before I go getting anything else, because that way I have a reference point with which to compare new bots to once I start getting them. I think I will respect the newer ones better if I first watch the older ones in action.

Are the older sim files supposed to be incompatible, and why wasn't there any change to the sysvars file?

7
Newbie / stuff for newbies?
« on: August 02, 2007, 01:39:38 AM »
I just got the program yesterday and since I'm a newb myself, I think I'm in an ideal position to suggest a thing or two that could make this place less overwhelming for new people. I hope this doesn't get on anyone's nerves...

-------
Maybe I'm a bit spoiled, but I like to look at pictures. A gallery showing examples of interesting bot behavior with short descriptions telling what's going on in the pictures would be nice. Something like that could go in the wiki. The current "screenshots" section is a good introduction to the program, but a gallery would be nice and show some of what bots themselves are capable of.

Along those lines, some screen captured videos of bots in action would be nice as well. A video that shows the evolution process of some bots would be cool, as would any that show interesting behaviors exhibited by bots.

A tutorial video that leads the watcher through some basic runs of the program might help as well, all though it isn't really necessary, it could help keep the UI in DB from being overwhelming.
-------

Of course, I could help out with this once I have a little bit of experience, although I don't know how long I'll be a part of this community. I'll probably be sticking around for a while though, because I find this stuff very interesting!

Pages: [1]