Code center > Darwinbots3

Bot DNA

(1/13) > >>

Numsgil:
I'm hoping to encourage some brainstorming about new DNA forms here.  I'll start with some of my own observations and ideas:

1.  First, the current DNA system has lead me to a strong conclusion.  The stack is very easily manipulated by evolution.  The memory locations much less so.  A new system should take advantage of the stack more fully, and reduce or eliminate dependence on memory locations.

2.  Viruses are key to most evo sims.  They should be encouraged.  But their method of propagation is a little overpowered in the current system, I think.  It should be easier for bots to spread viruses, and more difficult for viruses to enter a non receptive host.

3.  The linear nature of current DNA is limiting.  It should be easier for bots to run several much shorter strands in "parallel" than one long, linear one.  Especially with something like viruses, induced behavior should be additive and not necessarily disrupt existing behavior.

4.  Conditions shouldn't be separated from the stores that they influence.  Something like:
cond
*.nrg 5000 >
start
50 .repro store
stop

Would be better off looking like this:

*nrg 5000 > 50 .repro store

Maybe remove all the flow commands, or keep just start and stop (for junk DNA purposes).  I'm not quite sure how a system like this would work, but probably the condition operators (>, <, etc.) toggle whether stores work or not.

Probably there would be a parallel boolean stack (as there is now), and stores simply check against the top of this stack to see if they are active or not.

5.  DNA commands should be easily performed and understood by a human.  Things like the bitwise operators tend to make the DNA look even more indecipherable than is necessary.  Evolution will use whatever tools it has at hand, but humans don't like doing bitwise ANDing in their heads.

6.  Codules (basically sub functions that can't be set up recursively) are important for allowing branching logic.  I'm further advancing the idea that there would be "core" codules that interact in very defined ways, passing control to each other, and lesser codules, that act simply as functions, returning when they're done to where they were called.

7.  Probably something like half of the sysvars relate to vectors in one way or another.  I'm playing with the idea of using vectors as the basic type instead of integers.  But it's not as easy to do as I would like, so I may just sit on this idea.  Basically, it would be alot better to do something like:

*.refvel .move store

instead of

*.refvelup .up store
*.refveldx .dx store

8.  It's unrealistic to know exact details about your position, orientation, etc.  I'd move sysvars towards being entirely relative.  Sysvars would return information as if the bot is stationary and at the world origin (0,0).

9.  Arbitrary values need to be removed where appropriate.  For instance, instead of 100 .shootval store -2 .shoot store you might do something like 100 .nrgshot store.  Eyes also should probably be redone to return values representing distance more accurately.

10.  Most sysvars should be reworked to accept and return values in a normalized range.  Something like -1000, 1000.

11.  I was also playing with the idea of having all values be floating point in the range -1 to 1, but there are some places where this doesn't work out well (such as .body for instance)

12.  Where possible, sysvars should give and return information.  That is, act as both input and output.

13.  As a general rule, passing A to a sysvar and passing B to a sysvar should mean that passing their average gives a result that is related to A and B.  For instance, while -2 and -6 shots are both feeding shots, -4 is not.

14.  Where possible, choices should be dumbed down where these choices aren't important.  I was toying with the idea of making ties strictly for aggressive feeding and allowing only a single tie to be created per bot.  (The connective properties of ties would be moved to another mechanism).  Then instead of creating a tie and remembering its number, you'd just have to create a tie.  Feeding wouldn't need to know about which tie to use, because there would be only one.

Haven't worked through all the consequences of this yet, but it's the track of thinking I'm on.

Structure
This is the big one.  There are several ideas I've toyed with:
* The first involves creating a linear assembly line of codules.  Something like a pipeline.  After one codule is finished executing, it passes control to the next one, until finally the last one somehow gives values to sysvars to cause action.  Mutations could change the order of the codules being executed.  The result is somewhat similar to the evolution of metabolic pathways, but it's still too linear for my liking.
* The second involves a web of codules.  Each cycle, a codule would receive a stack filled with its input parameters, manipulate those parameters, and produce an output stack (the stack after it's done executing).  Codules could be connected to other codules by connecting one's output to another's input.  Sysvars would be simple codules that give output and receive input.

The problem is that it would then take several cycles for data to be processed from the inputing sysvars, through the DNA, to the outputing sysvars.  Also, this creates a problem when it takes one calculation 2 cycles to do, while a more sophisticated, branching calculation can take 10 or more.  DNA would be encouraged to sacrifice sophistication for simplicity, which is backwards of what I'd like to aim to achieve.

* An alternative is to run the DNA several times in a cycle, but here there are issues with how many times to run the DNA.
* Another idea is to simply prevent any looping at all (no recursion), which collapses the web into more of a feed forward neural net.  This is what I'm currently thinking.

Input sysvars would pass their values to any codules they're connected to.  These codules process their data and send it to the next codule.  But I'm not sure how to set it up so that the different execution paths don't end up with a racing condition against each other.-------------------------------------------------------------
That's pretty much all I have at the moment.

googlyeyesultra:
Alrighty, I'll through in my two cents. Or however much this turns out to be.

1) I have no strong opinions here, as I rarely run evolutions.

2) Ensure that viruses are still viable for F1 competition. After all, a virus loses not only its offensive power, but also its ability to spread through other bots (even if you don't kill them with it) if you make it too hard to infect other species.

3) I don't do evolutions much, but I can imagine shear havoc with parallel threads. For instance, two threads running simultaneously like this would be havoc (since they'd run infinite numbers of themselves, which presumably would be allowed, since you can run multiple threads at a time).

Here's an example in psuedocode:
Thread1
run parallel Thread2
run parallel Thread2
endthread

Thread 2
run parallel Thread1
run parallel Thread1
endthread

Not only would this be an infinite loop, but it's also going to start running ridiculous numbers of threads until the game either crashes or decides to kill the offending bot. So, I'd say a single thread at a time.

4) Make this optional, so that both forms of code are supported. This would actually allow for nested conditionals, and for more options and more control.

5) Humans don't like doing crazy logic operations? What? All those SG bots in the league weren't evolved, you know. Humans can create equally illegible code as evolution can. Besides, someone, someday will think of a use for that kind of thing en masse. No harm to having more sysvars, but there might be harm if they are removed.

6) Definitely agreed. Codules are a must. I'd say unless they use a goto command, have them pass control to the next codule linearly. Also, add a variable that allows a codule to reference what codule activated it, so that it would be able to pass control back to that, or to the codule after it.

7) Might be nice. Don't know. Would break most old bots, though.

8) I'm plus minus on this. Although it is a bit strange for a bot to know its exact locations, presumably a bot would be able to say "Oh, look, that's the big tree/lake/oasis/whatever! I know I'm not near any walls, 'cause I've been here before."

9) Eyes can be redone. I mildly disagree with changing shots, however. Personally, I don't consider the current system particularly bad, but it's really not a big deal.

10) Meh, 32000 is easy enough to remember. Once again, really either way would work. Just probably not worth spending time programming compared to things like metabolism, E-grid, etc.

11) Please, please don't. Please? Completely and totally break every scrap of bot code in existance? Not to mention we'd have to remember that we need to accelerate at .75, as apposed to a more standard 750.

12) Would probably work, so long as we can get the specifics ironed out. Would a bot ever be able to read the value it had placed in the variable, or only the readback value?

13) I honestly don't like this. A bit overcomplicated for you to read our minds and figure out what we all consider averages for variables. Besides, I'm still against multi-threading, so it would never be called on at the same time, and a lot of bots depend on later code overwriting earlier code. Not to mention this makes defensive genes worthless, as it would place the average in (which would still be likely detrimental to the bot).

14) What if you are tied to a bot, and another bot tied to you? How can you reference the tie you were attacked with to delete/leach from it? I am interested in any ideas for structural replacements to ties, as sophisticated multibots are nearly impossible, and mostly suck in combat.

15) Wait, you didn't have a #15. Oh, well.

Structure:
Use number two (the web), but let a bot run all of it's codules in one cycle. After all, we've already got SG bots. Do we really need further single codule bots? Also, making a codule per cycle means that shipping data off to small functions to perform common operations is ridiculously wasteful, which is relatively backwards to me. Copy and pasting the same formulas repeatedly should be more costly than making one function that repeatedly handles it.

By different execution paths, do you mean multi-threaded DNA? If so, well, you hopefully already know my opinion on simultaneous code threads.

Somehow I think that was more than 2 cents.

Trafalgar:
Edit: I don't know why the quotes aren't working, but I have to leave, so I'm not going to try to figure it out now.


--- Quote from: Numsgil ---I'm hoping to encourage some brainstorming about new DNA forms here.  I'll start with some of my own observations and ideas:

1.  First, the current DNA system has lead me to a strong conclusion.  The stack is very easily manipulated by evolution.  The memory locations much less so.  A new system should take advantage of the stack more fully, and reduce or eliminate dependence on memory locations.
--- End quote ---
It might be better to streamline stores by eliminating the store operator. If referencing an address with a . caused a store, then evolution might manage to evolve stores more often. This would make SGizing conditions impossible, though, unless there's a command to toggle between the old and new behavior.


--- Quote from: Numsgil ---2.  Viruses are key to most evo sims.  They should be encouraged.  But their method of propagation is a little overpowered in the current system, I think.  It should be easier for bots to spread viruses, and more difficult for viruses to enter a non receptive host.
--- End quote ---
I've been considering how to implement an antivirus for an evo sim without disrupting zerobot evolution. I was thinking a shepherd bot that would destroy any bots which are making viruses. The main reason is because virus-spreading isn't subject to mutation (as far as I know).

Also, I'm finding it a pain to deliberately infect a particular bot with a virus, since the virus shot actually flies off in a random direction, and completely ignores aim commands (I checked the source to verify that - the documentation on vshoot is wrong).


--- Quote from: Numsgil ---3.  The linear nature of current DNA is limiting.  It should be easier for bots to run several much shorter strands in "parallel" than one long, linear one.  Especially with something like viruses, induced behavior should be additive and not necessarily disrupt existing behavior.
--- End quote ---
If they run in parallel, coordinating numerous parallel code strands, making their conditions not conflict, and making them not fight over the same variables, would be a major pain in the ass.


--- Quote from: Numsgil ---4.  Conditions shouldn't be separated from the stores that they influence.  Something like:
cond
*.nrg 5000 >
start
50 .repro store
stop

Would be better off looking like this:

*nrg 5000 > 50 .repro store
--- End quote ---
This is essentially what SGizing is about, and with PyBot I can take it a step further.
I write this: setaim when (aim!=315) = 315
and it turns into this: 315 .setaim *.aim 315 sub sgn abs mult store
Which stores 315 into .setaim if *.aim doesn't already hold 315.

I also have almost all the stores in Guardian set up to only do the store if the variable isn't already set to whatever's going to be written to it. This slows down the sim further but reduces energy costs. Guardian is very energy efficient (except it splurges on movement speed and defenses) and very CPU inefficient (much of the reason is because the CPU inefficiency is necessary to make it so energy efficient).


--- Quote from: Numsgil ---Maybe remove all the flow commands, or keep just start and stop (for junk DNA purposes).  I'm not quite sure how a system like this would work, but probably the condition operators (>, <, etc.) toggle whether stores work or not.
--- End quote ---
As long as the condition operators continue to cost energy, and regular math and bitwise operators don't, it would still be more (energy) efficient for bot authors to use SGizing instead of the actual condition operators. As for evolution, I'm not sure how to make it work better. It seems to me that it works fairly well as-is. Real evolution generally takes thousands of years or more to evolve new abilities (like eyes, or thumbs, etc).


--- Quote from: Numsgil ---5.  DNA commands should be easily performed and understood by a human.  Things like the bitwise operators tend to make the DNA look even more indecipherable than is necessary.  Evolution will use whatever tools it has at hand, but humans don't like doing bitwise ANDing in their heads.
--- End quote ---
I for one use bitwise anding, both for SGized conditions, and for using a variable to store bitflags indicating what features in the bot should be toggled on. What's really indecipherable is when an evolved bot is shooting and turning and crap, and there's not a single store or reference to .shoot in the entire DNA. It's powered by a simple 'angle inc' or 'angle dec' at the beginning of a start. (dist would work too)


--- Quote from: Numsgil ---6.  Codules (basically sub functions that can't be set up recursively) are important for allowing branching logic.  I'm further advancing the idea that there would be "core" codules that interact in very defined ways, passing control to each other, and lesser codules, that act simply as functions, returning when they're done to where they were called.
--- End quote ---
While it could be useful to have functions (I already do something similar, but it's really more like macros), I don't think allowing something like goto and gosub would be a good idea. It would encourage evolution to create utterly unreadable spaghetti code. I would much rather it be linear, at least then you can try to follow it in your mind.


--- Quote from: Numsgil ---7.  Probably something like half of the sysvars relate to vectors in one way or another.  I'm playing with the idea of using vectors as the basic type instead of integers.  But it's not as easy to do as I would like, so I may just sit on this idea.  Basically, it would be alot better to do something like:

*.refvel .move store
--- End quote ---
I'm not sure if this is a good idea or a bad idea. Wouldn't it make some bots slower, from every multiplication, division, etc, being performed on two numbers instead of just one?


--- Quote from: Numsgil ---8.  It's unrealistic to know exact details about your position, orientation, etc.  I'd move sysvars towards being entirely relative.  Sysvars would return information as if the bot is stationary and at the world origin (0,0).
--- End quote ---
Having refveldn and the like be relative is already a pain in the ass, and having aimshoot be relative to your current angle is an even bigger one (since angle isn't, apparently). Making more things relative would not be a good thing, in my opinion.


--- Quote from: Numsgil ---9.  Arbitrary values need to be removed where appropriate.  For instance, instead of 100 .shootval store -2 .shoot store you might do something like 100 .nrgshot store.  Eyes also should probably be redone to return values representing distance more accurately.
--- End quote ---
This might make it harder for evolution to evolve bots that fire a variety of different shots. But who knows. The only shooting I've seen evolved so far was from .shoot dec.


--- Quote from: Numsgil ---10.  Most sysvars should be reworked to accept and return values in a normalized range.  Something like -1000, 1000.
--- End quote ---
Which sysvars? This could make things more confusing, but I don't know which ones you're talking about.


--- Quote from: Numsgil ---11.  I was also playing with the idea of having all values be floating point in the range -1 to 1, but there are some places where this doesn't work out well (such as .body for instance)
--- End quote ---
Haha. Yeah. This would break so many things.


--- Quote from: Numsgil ---12.  Where possible, sysvars should give and return information.  That is, act as both input and output.
--- End quote ---
That would be nice. It would also be nice if it were possible for a bot to tell if another bot is shooting things by looking at .shoot (I've tried, it's always 0).


--- Quote from: Numsgil ---13.  As a general rule, passing A to a sysvar and passing B to a sysvar should mean that passing their average gives a result that is related to A and B.  For instance, while -2 and -6 shots are both feeding shots, -4 is not.
--- End quote ---
I don't think this is feasible in practice. For example, shootval with info shots.


--- Quote from: Numsgil ---14.  Where possible, choices should be dumbed down where these choices aren't important.  I was toying with the idea of making ties strictly for aggressive feeding and allowing only a single tie to be created per bot.  (The connective properties of ties would be moved to another mechanism).  Then instead of creating a tie and remembering its number, you'd just have to create a tie.  Feeding wouldn't need to know about which tie to use, because there would be only one.
--- End quote ---
How about instead making tie commands default to tiepres if tienum is not set? This would help evolution without screwing up multibots and such. (I note that Guardian will tie to a hostile to destroy it even when it is already tied to a friendly or veggie)

As for structure changes, it seems to me that the current structure works decently well. I'm trying evolution with zerobots with ridiculously large genomes now too, to see how that works out (15k, quite close to Guardian's size).

I would suggest that info shots and memory writing with ties should set the variable after the rest of the cycle has run, so that on the next cycle, the bot can try to fix it if it is coded to. Right now they can instakill, and there's no way to stop it besides instakilling the attacker first.

Jez:

--- Quote from: Trafalgar ---Edit: I don't know why the quotes aren't working, but I have to leave, so I'm not going to try to figure it out now.
--- End quote ---
The forum only allows a certain number of quotes per post IIRC, try splitting your post in half or thirds and I'll move this one, or replace some of your quotes with [code]


--- Quote from: Trafalgar ---It might be better to streamline stores by eliminating the store operator. If referencing an address with a . caused a store, then evolution might manage to evolve stores more often. This would make SGizing conditions impossible, though,
--- End quote ---

Still a good idea IMO, 1G bots and the current evo bots can be a real pain to read.


--- Quote from: Trafalgar ---Also, I'm finding it a pain to deliberately infect a particular bot with a virus, since the virus shot actually flies off in a random direction, and completely ignores aim commands (I checked the source to verify that - the documentation on vshoot is wrong).
--- End quote ---

  The game was meant to have been changed to work like that, added to known bugs.

I'm also a fan of making bots own input relative.

Not a fan of any form of instakill, sysvars have been changed before because of that so I hope the mkshell/slime variable gets sorted.

Numsgil:

--- Quote from: googlyeyesultra ---3) I don't do evolutions much, but I can imagine shear havoc with parallel threads. For instance, two threads running simultaneously like this would be havoc (since they'd run infinite numbers of themselves, which presumably would be allowed, since you can run multiple threads at a time).

Here's an example in psuedocode:
Thread1
run parallel Thread2
run parallel Thread2
endthread

Thread 2
run parallel Thread1
run parallel Thread1
endthread
--- End quote ---

For threads, I'm imagining they don't communicate with each other.  They don't spawn new threads.  They just receive input from sysvars and output data to other sysvars.  Multiple data sent to the same sysvar is averaged together (which is why it's important that averaging two pieces of data results in a number that is related to the two pieces).  This is important because it allows a bot to receive additional DNA from another source and have its original DNA still be untouched.  Only its behavior will change.

So threading is more like having several extra people in identical cockpits driving the same robot you are.  The end robot behavior is like a democratic vote between all the pilots.


--- Quote ---5) Humans don't like doing crazy logic operations? What? All those SG bots in the league weren't evolved, you know. Humans can create equally illegible code as evolution can. Besides, someone, someday will think of a use for that kind of thing en masse. No harm to having more sysvars, but there might be harm if they are removed.
--- End quote ---

Humans can write complex things just fine.  It's reading them that's a pain.  Doubly so if it's an evolved bot.  Ideally a human should have little problem reverse engineering a section of DNA and understanding what it does.  This way evolution can become transparent.  This is one area where there's a conflict between the needs of Darwinbots as an evolution simulator, and the needs of Darwinbots as a battle bot arena.


--- Quote ---6) Definitely agreed. Codules are a must. I'd say unless they use a goto command, have them pass control to the next codule linearly. Also, add a variable that allows a codule to reference what codule activated it, so that it would be able to pass control back to that, or to the codule after it.
--- End quote ---

There are two methods I'm imagining for passing control from one codule to the next.  The first is like a pure goto statement.  Full control is moved from the first codule to the second.  The other method is more similar to the way functions work.  A secondary codule is called, manipulates the stack, and returns control to the codule that called it, where it called it.

In both cases, looping needs to be strictly impossible, or you'll end up with the possibility for an infinite loop in the DNA and a hung simulation.  Bad all around.


--- Quote ---7) Might be nice. Don't know. Would break most old bots, though.
--- End quote ---

I'm not too concerned about backwards compatibility.  I'm imagining something like "Darwinbots 3".  A whole new iteration of the program.  So many things changed that older bots just can't feasibly be moved to the new version in any sort of easy manner.


--- Quote ---8) I'm plus minus on this. Although it is a bit strange for a bot to know its exact locations, presumably a bot would be able to say "Oh, look, that's the big tree/lake/oasis/whatever! I know I'm not near any walls, 'cause I've been here before."
--- End quote ---

I'm hoping to come up with a reasonable system to address this problem.  Maybe something like pheremone markers bots can lay down.


--- Code: ---10) Meh, 32000 is easy enough to remember. Once again, really either way would work. Just probably not worth spending time programming compared to things like metabolism, E-grid, etc.
--- End code ---

The problem is that not all sysvars use the whole 32000 range.  Again, this is more closely tied with evolution that bot writing.  I feel it's important for evolution when the output for a commnd or sysvar can act as the raw input for another input or sysvar and produce reasonable results.


--- Code: ---11) Please, please don't. Please? Completely and totally break every scrap of bot code in existance? Not to mention we'd have to remember that we need to accelerate at .75, as apposed to a more standard 750.
--- End code ---

The main problem is that there are areas where it doesn't make sense.  Addition wouldn't really work, for instance.  Again, I'm not too concerned about backwards compatibility.


--- Code: ---12) Would probably work, so long as we can get the specifics ironed out. Would a bot ever be able to read the value it had placed in the variable, or only the readback value?
--- End code ---

I'm thinking sysvars would start out with the input value, and if a bot changes this value, then it acts as a write command.


--- Code: ---13) I honestly don't like this. A bit overcomplicated for you to read our minds and figure out what we all consider averages for variables. Besides, I'm still against multi-threading, so it would never be called on at the same time, and a lot of bots depend on later code overwriting earlier code. Not to mention this makes defensive genes worthless, as it would place the average in (which would still be likely detrimental to the bot).
--- End code ---

This depends on the variable.  I'd say 80% of sysvars are already averagable.  There are just a few exceptions.  .shoot comes to mind (but that's easy enough to split into several shooting sysvars).  As far as defensive genes go, I think primary defenses should be made more effective so the need for defensive genes is reduced.


--- Code: ---14) What if you are tied to a bot, and another bot tied to you? How can you reference the tie you were attacked with to delete/leach from it? I am interested in any ideas for structural replacements to ties, as sophisticated multibots are nearly impossible, and mostly suck in combat.
--- End code ---

This is still pretty raw in my mind, but at the moment I'm imagining having ties last only for a single cycle, or maybe be extremely brittle.  But either way, bots can't modify or delete ties made to itself.  A bot that is being sucked to death would need to find another means of removing the offending bot.  Maybe shooting it, or accelerating fast enough to break the tie, or brushing against another bot or shape to scrape the other bot off.

Basically, I'm imagining a combat system where it's better to leech on a bot that's much larger than you, shoot at a bot that's roughly the same size as you, and ingest (phagocytosis) a bot that is smaller than you.


--- Code: ---Structure:
Use number two (the web), but let a bot run all of it's codules in one cycle. After all, we've already got SG bots. Do we really need further single codule bots? Also, making a codule per cycle means that shipping data off to small functions to perform common operations is ridiculously wasteful, which is relatively backwards to me. Copy and pasting the same formulas repeatedly should be more costly than making one function that repeatedly handles it.
--- End code ---

Right, definately a problem.


--- Code: ---By different execution paths, do you mean multi-threaded DNA? If so, well, you hopefully already know my opinion on simultaneous code threads.
--- End code ---

Hopefully I've persuaded you with my above argument.

Navigation

[0] Message Index

[#] Next page