Bots and Simulations > DNA - General

Bots with Arrays

<< < (2/3) > >>

Moonfisher:
There should still be a limit though... at the very least to avoid endless loops.
Not sure exactly how codules work... is it just the ability to use functions ?

I can think of 4 descent ways to limit it... either put a cap on how many times you can call a codule per cycle, put a cap on how many times the same codule can be called in the same cycle, put a cap on how many codule bp can be executed per cycle.... OR let a cycle execute only a fixed amount of bp, so if your code is 1000 bp and each cycle processes 100 bp it'll take you 10 cycles to run through your code, you would still execute actions every cycle, but only the ones you've executed from your code in that cycle. If your code is 50 bp it would be able to run through it twice in a cycle, but you'd still only be able to execute actions once per cycle. The lower the amount of bp executed in a cycle, the more interesting I think it would be... if you only ran 1-10 bp per cycle then the dna length would get far more important. You could always make up for it by adding cooldown to certain actions like shooting and such. (And only zeroing out key mem locations if the action was executed)

Personaly I think the last option is the best one, it would also set a more constant time for code execution, so you don't end up with huge slow bots like Guardian...
And it would work well with functions, since you'll want to keep a tight main loop and only call the functions you realy need, so you can think fast in battle.
It's probably also more work getting it done, since you need to balance how many cycles different actions take with how many bp are executed per cycle, but I think it would be worth it  

Also I still think the bp pointer type and charging virus code manualy would be usefull and help make things interesting. I think self modifying code is one of the things that's realy going to make things more ineteresting in DB3 and it would be nice to have tools to take advantage of it. I definately think self modifying code would be a lot easier to controll with a pointer for it, currently we only have values and pointers to memmory locations. With a pointer I could choose to overwrite the code in one location with code from a different location just by iterating through it for each cycle changing one bp at a time.

So those would be my revised sugestions :
- 1 bp executed per cycle, with different cooldown on different actions.
- pointer type for locations in the code
- and tailored viruses charged one bp at the time

The worst issue I can see for the 1bp per cycle thing is the movement and physics and eyesight and all the other stuff slowing things down. Best easy answer I can think off is to only update movement, physics and all that every X cycles (Something that fits well with the cooldown on all the actions).

Prsn828:
It will probably limit by putting a maximum size on a call stack.

When you call more than your share of codules, they just stop listening to the calls.

Ta-183:
This would all be a crapload easier if we had an IDE. Anyone want to chance building one?

Numsgil:

--- Quote from: Moonfisher ---There should still be a limit though... at the very least to avoid endless loops.
--- End quote ---

Basically you can't call a codule that is already on the call stack (the call just fizzles).  The only downside to this method is that you can't call the same codule recursively.  The other methods you listed work too, but IMO they're less elegant.


--- Quote ---Not sure exactly how codules work... is it just the ability to use functions ?
--- End quote ---

More like sub routines, but yeah, basically.  There's a "root" codule, which is basically what the DNA is now.  You can then call other codules, creating a call stack which remembers where in the previous codule you were, on and on down into your code.  If you call a non existent codule, it tries to find the next "closest" codule to call instead, so it should play nice with evolution.


--- Quote ---Personaly I think the last option is the best one, it would also set a more constant time for code execution, so you don't end up with huge slow bots like Guardian...
And it would work well with functions, since you'll want to keep a tight main loop and only call the functions you realy need, so you can think fast in battle.
It's probably also more work getting it done, since you need to balance how many cycles different actions take with how many bp are executed per cycle, but I think it would be worth it  
--- End quote ---

This is how most other ALife sims work.  But from what I've read, this actually favors "gray goo" bots over complex behavior.  Evolve 4.0 had more successful sims when "free instructions" were increased.  This is actually one of the things about Darwinbots which I think makes it work so well.

And if you think in terms of real life, DNA is a massively parallel computer.  The longer the DNA gets, the more processing power it has, not less.


--- Quote ---Also I still think the bp pointer type and charging virus code manualy would be usefull and help make things interesting. I think self modifying code is one of the things that's realy going to make things more ineteresting in DB3 and it would be nice to have tools to take advantage of it. I definately think self modifying code would be a lot easier to controll with a pointer for it, currently we only have values and pointers to memmory locations. With a pointer I could choose to overwrite the code in one location with code from a different location just by iterating through it for each cycle changing one bp at a time.
--- End quote ---

I've been hesitant to go down that way, for various reasons.  Mostly because it's a super weapon, which means the code has to have special exceptions everywhere to make sure it's not abused.  There are probably clever ways around those problems, but I don't want to add it just for the sake of adding it either.  The main use I can think of would involve viruses, and for DB3 I'm specifically working to remove the need or ability to self police your genome (stronger defenses against virus infection, and inability to self modify your genome at all.  Viruses would work less like retro viruses (injecting into your genome) and more like normal RNA viruses (another genome in your bot vying for control)).

But if you (or anyone) can think of specific use cases I can probably design around them.

Moonfisher:

--- Quote from: Numsgil ---Basically you can't call a codule that is already on the call stack
--- End quote ---
But what if I have 3 codules A, B and C, and A calls B, B calls C and C calls A ? (The classic downfall of some Garbage collectors)


--- Quote from: Numsgil ---This is how most other ALife sims work.  But from what I've read, this actually favors "gray goo" bots over complex behavior.  Evolve 4.0 had more successful sims when "free instructions" were increased.  This is actually one of the things about Darwinbots which I think makes it work so well.

And if you think in terms of real life, DNA is a massively parallel computer.  The longer the DNA gets, the more processing power it has, not less.
--- End quote ---
I agree that IRL longer dna should mean more processing power, but I was mostly refering to the simulation speed. (Also a bot with more dna wouldn't have less processing power, just the same as shorter dna (Making it slower).)

But I think the issue is just how often you choose to update the world. For example if you only updated every 32000 cycles, even the longes possible bots would be able to comlete their code.
But the advantage would be that self modifying code in a small bot can accomplish a lot internaly during that time, and multibots can comunicate and stuff like that. (Since actions that don't affect the physical worls would be able to have a lower cooldown period.)
The issue I was most worried about would be the dna being out of sync with the update of the physical world, but I don't think it should be an issue as long as sysvars only get errased once they've been used.
If you updated every 10K cycles I think most bots wouldn't even notice.
For some handauthored bots it would probably help to have a flag being set every time the physical world has been updated (Although there should be plenty of other ways to tell).
But after thinking about it I think viruses would probably be the main issue, it would be a lot harder to create viral defences. You wouldn't just be able to block negative effects in the last gene, you would have to check for infections every time the physical world is updated.
So I know it makes things complicated, but I don't think evolution would suffer, and it would make some aspects far more interesting.


--- Quote from: Numsgil ---I've been hesitant to go down that way, for various reasons.  Mostly because it's a super weapon, which means the code has to have special exceptions everywhere to make sure it's not abused.  There are probably clever ways around those problems, but I don't want to add it just for the sake of adding it either.  The main use I can think of would involve viruses, and for DB3 I'm specifically working to remove the need or ability to self police your genome (stronger defenses against virus infection, and inability to self modify your genome at all.  Viruses would work less like retro viruses (injecting into your genome) and more like normal RNA viruses (another genome in your bot vying for control)).

But if you (or anyone) can think of specific use cases I can probably design around them.
--- End quote ---

Well I don't know what you have planned in that area, and it's hard for me to speculate till I've had a look at how the dna will work in DB3.
I imagined the pointer would be usefull for removing infections and for manualy charging virus code. Figured it might make evo sims more interesting.
But it sounds like you may be rethinking the self modifying code idea, and generaly the way viruses work. So it's hard to say anything realy.

Navigation

[0] Message Index

[#] Next page

[*] Previous page