Darwinbots Forum
Bots and Simulations => Bot Tavern => Topic started by: bacillus on January 11, 2010, 09:42:41 PM
-
If anybody is interested in creating a multibot, I'm free for the next few days, so will have time to start a commune bot project. The idea is to have a bot that has several specialized cell types, each of which follows a set behaviour. Feel free to work on your strength, be it creating a competitive cell, creative strategies, communications etc. I don't really care how good you are, the idea is not to make the best bot, or even a bot that can survive against other non-veggies, but to create a diverse and interesting multibot. I can probably handle the main structure; to start, the following cells will need to be implemented:
-Body cell-this will tie everything together, and handle communications, food sharing etc. I should manage this as long as all required inputs and outputs are documented.
-Tentacle cell-the idea is to have these cells spawn a straight line of tentacle cells-the one connected to a body cell is the root, the tip is the feeding cell and the middle ones are tentacles that move the tip. Ideally, they won't generate information, but will be able to read information, so not to disrupt the body cell's mechanism.
-Eye cell-these will feed info into the body cells about food, which then get transmitted through the body and read by the tentacles.
-Brain cell-these cells will read multiple eye cells and send compiled information to the root body cell (not required, but could make it easier)
-Reproduction cell-asexual for now. This bot won't neccessarily interact much with the rest of the bot, but is important as any new cells it spawns must NOT connect to the main organism.
We'll see how we get this bit down before coming up with more elaborate body bits, so we can get a feel of standard interaction techniques.
So who's game?
-
I should probably clarify the bit about the body cells. The idea is to have a central line of cells that act as a sort of spine/stem cell for the bot; the body cells will then spawn all other kinds of cells. How we do this will probably be random to boot, but can be worked out later.
-
I'd help but im not very skilled in making regular bots, let alone multi bots. If its ideas you want though you could have your tentacle cells form a defensive bubble around any veggies they capture, kind of like shielding them against other bots and taking advantage of the unlimited nrg they provide.
-
Doesn't matter if you can make MBs or not, or if you understand all the code. All you need is to know to read tie info (tinX vars) and whatever code you need to write what you want to do. If you've ever done anything involving programming, just think of all the tasks as interfaces. Just tell me what data you need to read, and I'll provide it. I can handle the structure, as long as you handle the behaviour of the individual cells. For example:
'NOTE-I need the x-position for food in port 2, and y-pos in port 3
cond
*.type .tip =
start
*.tin2 *.tin3 angle .setaim store
5 .up store
stop
I would then make sure that this bot gets the information it needs, and is put in the correct part of the organism, and then all you have to do is focus on making the tip move or eat or whatever you want it to do. the Type var can be used to remember what sort of cell you are supposed to be, and just write the name of the cell type as above and I'll integrate it.
-
Are you starting from scratch, or using something like seasnake as a base?
-
I'm going from scratch. I've learned a lot about MB control through recent trial and error experiences, and although I wanted to do this project for ages, only now I believe to be able to make a bot modular enough that people can plug in individual genes without having to completely rewrite everything.
EDIT=> I have the glimmerings of the beginnings of a core structure. The front body bit will only spawn 'head' components, the middle will only spawn up to two 'tentacle' components (later we could change this to lateral nerves to allow for more complex structures), and the back acts as the reproductive component and is capable of growing new body bits, thus making it a body cell itself and creating a new end tip...
...well, that's the plan anyway
Once somebody starts coding something, I think I'll have enough to start properly designing the bot. Seriously, at this point something simple that moves or turns to look for food and eats will be enough.
-
So the back part of the organism produces the body pieces and the rest are sterile? This could be a good defense against random mutations since you won't have a completely cancerous arm that unfairly steals nrg from the rest of the organism. However how do the individual cells travel from their place of birth to where their needed without getting lost.
-
Not really. As mentioned above, body bits spawn specialized cells, which in turn may spawn more cells (like tentacles). The back will be the only cell to further the central 'spine' growth/make a new organism.
-
Will we use one of the HLL implementations of DB language? Or will we code in DB "assembly"? I thought there was something called pybot at one time to write dbcode in a hll...
-
As long as the code is compatible, I don't think it matters. I will put everything together in good ole-fashioned DB code though.
-
Currently I'm watching a giant snake threading itself slowly through a field of veggies . As sign of progress!
'Primordius
'Community MB
'BOT NOTES
'The spine bits will alternate between tie numbers 2 and 3. This allows them to
'communicate both ways. Ties are used to identify each adjacent bot's
'function, and by using .readtie we can than switch between those.
'IO PORT DESCRIPTION
'01-Conspec
'02-Birth control-What is assigned type?
'03-Birth control-What should my tie number be?
'CUSTOM LOCATIONS
'type-what kind of cell am I?
'firsttie-what is the tie ID of the first tie I made?
def type 989
def firsttie 990
'CUSTOM VARS
'TYPE VARS
def head 0
def spine 1
def tail 2
cond
*.robage 0 =
start
1221 .out1 store
1221 .tout1 store
*.in3 ++ .tie store
*.in3 ++ .firsttie store
stop
cond
*.robage 20 =
start
*.tin2 .type store
stop
cond
*.tin1 *.tout1 !=
start
*.tiepres .deltie store
stop
start
*.firsttie 2 sub sgn abs .out3 store
*.nrg *.body add 15 div *.body sub dup .strbody store
- .fdbody store
40 .stifftie store
5 *.velup sub .up store
50 .sharenrg store
stop
cond
*.numties 0 =
*.nrg 5000 >
*.robage 20 >
start
.tail .tout2 store
1 .out3 store
.head .type store
50 .repro store
628 .aimdx store
stop
cond
*.type .head =
start
100 .sharewaste store
-4 *.eye1 *.eye9 sub sgn 0 floor mult *.eye1 *.eye8 sub sgn 0 floor
mult *.eye1 *.eye7 sub sgn 0 floor mult *.eye1 *.eye6 sub sgn 0
floor mult *.eye1 *.eye5 sub sgn 0 floor mult *.eye1 *.eye4 sub sgn 0
floor mult *.eye1 *.eye3 sub sgn 0 floor mult *.eye1 *.eye2 sub sgn 0
floor mult 4 *.eye9 *.eye8 sub sgn 0 floor mult *.eye9 *.eye7 sub
sgn 0 floor mult *.eye9 *.eye6 sub sgn 0 floor mult
*.eye9 *.eye5 sub sgn 0 floor mult *.eye9 *.eye4 sub sgn 0 floor mult
*.eye9 *.eye3 sub sgn 0 floor mult *.eye9 *.eye2 sub sgn 0 floor mult
*.eye9 *.eye1 sub sgn ++ sgn mult add -3 *.eye2 *.eye9 sub sgn ++ sgn
mult *.eye2 *.eye8 sub sgn 0 floor mult *.eye2 *.eye7 sub sgn 0 floor
mult *.eye2 *.eye6 sub sgn 0 floor mult *.eye2 *.eye5 sub sgn 0 floor
mult *.eye2 *.eye4 sub sgn 0 floor mult *.eye2 *.eye3 sub sgn 0
floor mult *.eye2 *.eye1 sub sgn ++ sgn mult add 3 *.eye8 *.eye9 sub
sgn ++ sgn mult *.eye8 *.eye7 sub sgn 0 floor mult *.eye8 *.eye6
sub sgn 0 floor mult *.eye8 *.eye5 sub sgn 0 floor mult *.eye8 *.eye4
sub sgn 0 floor mult *.eye8 *.eye3 sub sgn 0 floor mult *.eye8 *.eye2
sub sgn ++ sgn mult *.eye8 *.eye1 sub sgn ++ sgn mult add -2 *.eye3
*.eye9 sub sgn ++ sgn mult *.eye3 *.eye8 sub sgn ++ sgn mult *.eye3
*.eye7 sub sgn 0 floor mult *.eye3 *.eye6 sub sgn 0 floor mult
*.eye3 *.eye5 sub sgn 0 floor mult *.eye3 *.eye4 sub sgn 0 floor mult
*.eye3 *.eye2 sub sgn ++ sgn mult *.eye3 *.eye1 sub sgn ++ sgn mult
add 2 *.eye7 *.eye9 sub sgn ++ sgn mult *.eye7 *.eye8 sub sgn ++
sgn mult *.eye7 *.eye7 sub sgn 0 floor mult *.eye7 *.eye6 sub sgn 0
floor mult *.eye7 *.eye5 sub sgn 0 floor mult *.eye7 *.eye4 sub sgn ++
sgn mult *.eye7 *.eye2 sub sgn ++ sgn mult *.eye7 *.eye1 sub sgn ++
sgn mult add -1 *.eye4 *.eye9 sub sgn ++ sgn mult *.eye4 *.eye8 sub sgn
++ sgn mult *.eye4 *.eye7 sub sgn ++ sgn mult *.eye4 *.eye6 sub sgn
0 floor mult *.eye4 *.eye5 sub sgn 0 floor mult *.eye4 *.eye3 sub
sgn ++ sgn mult *.eye4 *.eye2 sub sgn ++ sgn mult *.eye4 *.eye1 sub
sgn ++ sgn mult add 1 *.eye4 *.eye9 sub sgn ++ sgn mult *.eye4 *.eye8
sub sgn ++ sgn mult *.eye4 *.eye7 sub sgn ++ sgn mult *.eye4 *.eye6
sub sgn ++ sgn mult *.eye4 *.eye5 sub sgn 0 floor mult
*.eye4 *.eye3 sub sgn ++ sgn mult *.eye4 *.eye2 sub sgn ++ sgn mult
*.eye4 *.eye1 sub sgn ++ sgn mult add 0 *.eye5 *.eye9 sub sgn ++
sgn mult *.eye5 *.eye8 sub sgn ++ sgn mult *.eye5 *.eye7 sub sgn ++
sgn mult *.eye5 *.eye6 sub sgn ++ sgn mult *.eye5 *.eye4 sub sgn ++ sgn
mult *.eye5 *.eye3 sub sgn ++ sgn mult *.eye5 *.eye2 sub sgn ++ sgn
mult *.eye5 *.eye1 sub sgn ++ sgn mult add .focuseye store
stop
cond
*.numties 0 =
start
.head .type store
stop
cond
*.type .head =
*.eyef 0 >
*.in1 *.out1 !=
start
*.refxpos *.refypos angle .setaim store
stop
cond
*.type .tail =
*.nrg 10000 >
start
628 .aimdx store
50 .repro store
.tail .tout2 store
.spine .type store
stop
cond
*.in1 *.out1 !=
*.eye5 40 >
start
-6 .shoot store
stop
cond
*.waste 250 >
*.type .head =
start
*.waste .shootval store
-4 .shoot store
stop
-
Okay, the basic structure is almost complete. I had to relabel 'body' to spine, as the bots were doing funny things to their body mass levels; the only problem I'm having now is to get the damn bots to tie on birth.
EDIT=> I think I fixed the problem. It might make the spine connection only work one way, but the many-to-one inputs should still works using .tieloc and .tieval.
OK, the current bot should be enough to get started. ATM, if you want to design a new cell type, just post the genes along with a description with its position on the bot and I'll try massage it in. Otherwise, improvements on the current bot, such as steering, feeding etc. are also welcome.
-
This reminds me, I was trying to modify Seasnake so it would use Peter's "caterpillar" movement scheme. Do you think that would be easy to do? I was thinking of using that as the basis for a 0% bang efficiency evosim. . . The goal is to encourage MB evolution.
-
I have an idea which im trying at the moment. Its the tentacles. They would sweep around (actually they don't even have to move, just keep up with the main bot.) and snatch up veggies and fire at enemies. when a tentacle grows big enough it could form into a body segment and sprout more tentacles, like a tree grows branchs that grow more brances. This would make reproduction easy since all the bot would have to do to reproduce is to detach one of these branches and send it out on its own. Anyway im working on some of the basic code for them if anyone has ideas or anything.
-
Ooh, fascinating. The 'branching out' idea was one I was thinking of putting in later on, as to create a branched 'nerve network'. The tricky bit, though, is coordinating motion in vastly non-linear systems. The original idea of reproduction was to create a new cell and delete the tie it makes, but I think generalizing to breaking off should work. After all, each cell knows its initial tie ID, so if it realizes it broke off from the main body it could easily become a new head. The new tail is a different story altogether...
I can't actually remember Caterpillar. Is it the one that stretches and contracts ties? Easy with two cells, but in such a huge system...
-
Ideally the tentacles would "curl" around food and pull it in into something akin to a stomach but for the moment I just want to get it to grow, move, and get the veggies in the first place.
By the way would a virus be ok if it was shot at a captured veggie. Just to delete all its dna wich might cause it to 'resist', mabey have it do something usefull as well (like move into the stomach on its own or reproduce, etc.)
-
Preferedly not, unless you've tested it meticulously. Viruses can't be aimed, and once they hit you back they start doing unexpected stuff to you. Viruses tend to be used very rarely out side combat (where they ususally degenerate themselves along) or evosims (I remember somebody, perhaps EricL, got a sim going where bots would shoot a virus containing all their DNA after reproduction as a safeguard against mutations.)
Btw. I just found out I may be called into Wehrplicht in germany, despite living on the other side of the world (quite literally) . Another mess for me to sort out...
-
Thats not good...
-
Another delightful surprise from the blue. Should be all right tough as long as no-one invades during that time
Say, is anybody else getting a big lag on this site? Everything else seems to work OK. ATM it's quicker to log out and in again than reload the main page
-
Um, how are they going to know what type of cell they are. Can it/Does it store the type of bot the original cell intended it to be in a epigenetic memory location. And if it does would that be transfered if the birth tie was broken the next cycle by the parent tieing to its kid. Im trying to code the tentacle but It needs to be compatible with the type of cell that spawned it so it knows when its a tentacle cell and then only does tentacle cell things. Im confused about the code you wrote to. Doesn't def work like "Def varname MemoryLocation" and if it does then why do you have:
'TYPE VARS
def head 0
def spine 1
def tail 2
none of those are free vars, are they? Sorry im just not good at figuring things out.
-
you don't have to use them as memory vars; remember .X gives you the number of location X, so using the same method constants can be defined. They are simple convenient labels. The actual type is stored in the location .type.
-
The MB project sounds very interesting
my scripting skills are too amateur and I feel unworthy to attempt this in the presence of such great DB programmer people
-
Don't worry about it, somebody else will handle the hard stuff. For example, any genes that are an improvement on the current fill-in feeding gene would be great. The idea is to have scraps of code from everybody melded into one, regardless of skill level.
-
you don't have to use them as memory vars; remember .X gives you the number of location X, so using the same method constants can be defined. They are simple convenient labels. The actual type is stored in the location .type.
I never thought about using variables as constants before. Kind of an oxymoron. Anyway I figured out how to get past the schools internet blocker. No I didn't hack it or anything. Just use google cache and for some reason it still lets you read and post here. Im actually at home right now but I could post this from school if I wanted to.
EDIT: I just found out custom variables are case-sensitive. That really screwed up my bot at first because I like to use variables like 'AgeWhenTied' or 'LastBotNumber' to keep the words seperate but I just end up typing them like 'agewhentied' or 'lastbotnumber' cause its faster. Not a big deal, just didn't see anything about it in the wiki.
-
Odd, usually they are case-insensitive.Btw. I usually only use constants if you keep having to refer to them (eg. sustbody, if you want to keep the body level constant, it's usually faster to make a constant and tweak that instead of finding the number in the code.), or if a number has a special meaning (spine and head, for example.)
-
I almost have the tentacle ready to test. Its funny how the things you think are going to be the hardest turn out to be easy and the little things you didn't even consider become real complicated real quick . Communications, coordination, etc. all turned out to be fairly easy, but getting the bots to reproduce in a straight line! Why would you even consider that!
-
If you post the code, we can try fix and/or integrate it...
-
I will when im finished with it. Right now its just a mess of random genes.
-
Just remember that communications still come from the main spine, so at least allow some flexibility for integration. Don't see why reproduction is a problem, I could handle that if neccessary. It sounds like you're making an independent bot ATM...
-
Pretty much ya. I can change it later fairly easy though. The idea was to just get it to work.
-
Sweet as, you do that.
-
Heres what I got so far. sorry its not much, my computer I had it saved on went down for a while. I now have it saved to a gmail account just in case.
[div class=\'codetop\']CODE[div class=\'codemain\' style=\'height:200px;white-space:pre;overflow:auto\']def botnumber 70 'what number I am in the tentacle chain
def lasttienum 71 'last tienumber (nessasary for comunication) I found out you
'can use .tiepres. May have to change this
def agewhentied 72 'what age was I when I tied to my first bot (or got tied to)
def whichside 73 'which side of the tentacle will I search for food?
def clock 74 'turn clockwise or counter clockwise?
def foundveg 75
'========================================================================
'touts and outs and ins tins etc.
' out1 = numties
' tout1 = my botnumber
' out2 = botnumber
' tout2 = which side of the bot my search pattern is assigned
' tout3 = refxpos
' tout4 = refypos
' tout5 = communication state
'========================================================================
'reproduce to form a new tentacle
'NOTE: this is temporary to test the performance of the tentacle, my idea
' is that the tentacle will grow longer over time when theres nrg.
cond
*.foundveg 1 !=
*.botnumber 20 !=
*.robage 20 >
*.eye5 0 =
start
*.nrg 20 *.botnumber sub div 100 >
*.nrg 20 *.botnumber sub div *.nrg div 100 mult .repro store
stop
'what to do when I see my new offspring
cond
*.numties 1 =
*.multi 1 =
*.refeye *.myeye =
*.reftie *.myties =
*.refmulti 0 =
*.in1 0 =
start
*.lasttienum 1 =
.tie inc
not
.tie inc inc
stop
'set my out1 (can change if nessacary) to show if im part of the main bot yet
'so when im a new cell I won't be tied to two tentacles instead of just one
cond
*.out1 *.numties !=
start
*.out1 *.numties store
stop
'store a value in .lasttienum to find what tie connects to the bot behind me
cond
*.multi 1 =
*.lasttienum 0 =
start
*.tiepres .lasttienum store
stop
'Find out what cell number I am etc, once im a multibot
cond
*.multi 1 =
*.botnumber 0 =
start
*.readtie *.tiepres != 'this makes sure it stores .tieread before it does
'anything
*.tiepres .readtie store
not
*.tin1 1 add .botnumber store
stop
'store .botnumber in tout1
cond
*.tout1 *.botnumber !=
start
*.botnumber .tout1 store
stop
'find age when tied
cond
*.multi 1 =
.agewhentied 0 =
start
*.robage .agewhentied store
stop
'store my bot number in my out2
cond
*.botnumber *.out2 !=
start
*.botnumber .out2 store
stop
'search for food
Cond
*.foundveg 1 !=
*.multi 1 =
start
*.clock 0 = and
100 .aimdx store
*.clock 1 = and
-100 .aimdx store
stop
'check the bot behind me if I should be searching on the left or the right
cond
*.whichside 0 =
*.readtie *.lasttienum =
start
*.tin2 1 =
.whichside inc inc
.tout2 inc inc
*.tin2 2 =
.whichside inc
.tout2 inc
stop
'turn untill I see bot next to me
cond
*.eye5 0 >
*.refeye *.myeye =
*.reftie *.myties =
*.numties 2 =
start
*.in2 *.botnumber 1 sub =
*.whichside 1 = and
*.in2 *.botnumber 1 add =
*.whichside 2 = and or
*.clock 0 = and
.clock inc
*.in2 *.botnumber 1 add =
*.whichside 1 = and
*.in2 *.botnumber 1 sub
*whichside 2 = and or
*.clock 1 = and
.clock dec
stop
'if I have one tie then just turn untill I see bot behind me
cond
*.eye5 0 >
*.numties 1 =
*.refeye *.myeye =
*.reftie *.myties =
*.in2 *.botnumber 1 sub
start
*.clock 1 =
.clock dec
*.clock 0 =
.clock inc
stop
'when I see food I? (should I put a refshell/slime condition here?)
cond
*.eye5 0 >
*.refshoot 0 =
*.reftie 0 =
*.refkills 0 =
start
*.refxpos *.refypox angle .setaim store
.tie inc inc inc 'I only want to shoot one tie but this might shoot untill it hits
*.foundveg 0 =
*.foundveg inc
*.tout3 *.refxpos !=
*.refxpos .tout3 store
*.tout4 *.refypos !=
*.refypos .tout4 store
*.tout5 1 !=
.tout5 1 store
stop
Please note that its only half complete. I just wanted to show the direction I was going in and ask if anyone has any suggestions. Right now my problem is trying to get the bots to pass the veggies on. I want the bot to calculate the diference between itself and the veggie, then set an angle between that and the bot next to it and use tieloc/tieval to set the veggies aim toward the bot next to at while firing memory shots at it to make it move. It will comunicate its refxpos refypos through the tie and the next bot will set its aim toward the veggie and fire a tie at it when it sees it, overiding the previous tie. I think I can make it compatible with the main bot but I'll have to add a gene to every bot that only activates when its a tentacle cell.
-
I'll be away for a week, but I'll have a look at the code when I get back
-
well hopefully I'll have it working by then .
-
I think I see where you're going, but just to clarify a few things:
X inc inc will increment location X, then increment zero. you have to implicitly say X inc X inc or X dup inc inc.
The repro gene should multiply by 100 first, not last, otherwise rounding means you either end up with zero or 100. (No fractions or decimals!)
cond
*.out1 *.numties !=
start
*.out1 *.numties store
stop
make that second *.numties simply .numties and it should be sweet.
*.lasttienum seems to refer to the first, not last, tie, so should probably be left seperate from .tiepres, which refers to the most recent tie. Other than that, the code seems pretty good. You may want to look into taking advantage of OCULUS, I'll be using it here and there anyway...
I was thinking that using 31999 rnd ++ .tie store to make a virtually unique tie ID could be helpful for organizing ties. Do you think this would be a good idea to implement?
-
X inc inc will increment location X, then increment zero. you have to implicitly say X inc X inc or X dup inc inc.
Really? this might explain many errors in bots i've made in the past.
make that second *.numties simply .numties and it should be sweet.
oops.
*.lasttienum seems to refer to the first, not last, tie, so should probably be left seperate from .tiepres, which refers to the most recent tie. Other than that, the code seems pretty good. You may want to look into taking advantage of OCULUS, I'll be using it here and there anyway...
I'll rename it. I started with the concept that you had to reproduce then shoot a tie at your offspring but maybe you can just harden your birth tie. Also i completely left out tie angles and hardness and the like. If it becomes a problem and it probably will, i'll have to come back to it. can't you just store a negative number in one of the tie angle sysvars to make your bots free rotating.?
I was thinking that using 31999 rnd ++ .tie store to make a virtually unique tie ID could be helpful for organizing ties. Do you think this would be a good idea to implement?
Im not that familiar with the bitwise commands yet. But whats the point of having unique tie ids. You might be able to eliminate unique bot ids, and have every bot be identified by its ties, but that just makes it even more unessacarly complicated. If you plan on creating a new cell type, like a brain (that would be really, really cool), where the cells are connected to as many neighboring cells as possible, it could be usefull. You could set aside a memory range for every tie and when it made it and access it like an array. I suppose the advantage to a brain would be you could take advangtage of a lot of bots collective memory and processing power and combine it into one. it would be taxing on the bot though. Maybe you could make it run intirely on incs and decs to save nrg.
-
The tie ID is not that complicated really. It creates a random number between 0 and 31999, then increments it as 0 would not form a tie. The point of doing so is that a bot can remember which tie formed when, and allows the child to form the tie on birth without having to read parent info, which seems kind of suspect (the only other option is static tie ID, which disables tie switching completely). The parent can't bond on the birth cycle, and you'll be surprised how often they fail to bond after the birth cycle, becuase they move out of alignment or one of them turns or another bot gets in the way, etc...
Maybe you could make it run intirely on incs and decs to save nrg.
The trouble with this is that until loops are implemented in DB3 (and that's not looking remotely close to being likely), inc/dec commands allow only a fixed variation. Increasing 50 to 100, for example, could be better done with *.X 50 add .X store than X inc X inc X inc etc. (fixed) or X inc over 50 cycles (way too slow).
-
The parent can't bond on the birth cycle, and you'll be surprised how often they fail to bond after the birth cycle, becuase they move out of alignment or one of them turns or another bot gets in the way, etc...
I know. Im trying to avoid systems that are set in stone and require precise timing and coordination. If a parent fails to tie to the child the first time it sees it then it will just try again the next time it sees it and if some random factor makes the child drift away and breaks its birth tie then it will just not do anything and die or get attached to by another tentacle on another bot.
The trouble with this is that until loops are implemented in DB3 (and that's not looking remotely close to being likely), inc/dec commands allow only a fixed variation. Increasing 50 to 100, for example, could be better done with *.X 50 add .X store than X inc X inc X inc etc. (fixed) or X inc over 50 cycles (way too slow).
10 incs/decs is equal in cost to 1 store. Im not sure how a brain would work though. I suppose you could have it simulate a neural network, randomly tieing to other bots and changing their wieghts and stuff. Maybe you could put boolean logic in there to and allow the bots to use an array of memory as, well memmory. Im not sure how you would get it to learn though.
-
cond
*.out1 *.numties !=
start
*.out1 *.numties store
stop
make that second *.numties simply .numties and it should be sweet.
.numties is intended as a read location. If you store info there it will just be reset next cycle. Why are you doing this?
-
An inadvertent reversal of commands perhaps?
I think that it would actually be a great idea to implement a backup gene like your tie former...
-
Ya, it was a typo .
-
Has the piece of code you posted vanished, or has the madness finally descended?
-
umm... both?
-
This sounds incredibly interesting. While I'm not doing anything remotely related to DB at the moment, come June I will find myself with boatloads of free time until I decide to enroll in some place of higher education, and I'm planning to finally give a crack at SF2.2 (the easier route though. I'm not even going to try to finish the far more complicated behaviors), so I may lend some sort of assistance here.
And I'll start with conceptual advice, one of my best skills.
A thought on the 'brain' cells. In a brain, there are processing centers that carry out the calculations and logical decisions dictated to it. Then, there are cells which serve strictly as memory. A 'brain' would require both, say, a veritable 'frontal lobe' and memory cortex. The frontal lobe would perform the actual 'thinking' of the bot, while the memory cortex would simply serve as a memory bus, storing jack in its memvars except what its told to. When the memory cortex grows large enough, it may be of benefit to design a 'memory bus', a middleman between the frontal lobe and the memory that could possibly help reduce processing time (in DB cycles, of course) by dynamically creating and allocating memory arrays for different kinds of data. Of course, storing different 'memories' would require an entirely new metasystem in DNA assembly to equal something of a filesystem and filetypes, but that is another discussion entirely. Read and write times would be measured in multiple cycles, so the memory cortex would be used more like a hard drive than RAM, or, more akin to microprocessors, RAM as opposed to registers. It would be wise to devote different cells of the brain to memory read/write tasks, reading and writing 'memories' to and from storage as required, such as part of the brain deciding to pass the time by performing a statistical analysis of past veggie growth and colony size.
Persistent memory storage alone, as well as any kind of statistical system, not to mention the concept of 'memories' (idea- try and implement some kind of system as used in Dwarf Fortress, where significant events, such as mass deaths, attacks, veggie surplus, etc, are stored as 'memories'.) absolutely REQUIRES the use of auxiliary cells as memory cells. 1000 integer slots is far from enough to store this kind of data when there are other things to be done. If anyone would care to try, it would be nice to see a proof-of-concept bot that would create and maintain "dead-weight" memory cells that it ties to and stores and retrieves data, such as veggie positions and densities over time, its health over time, what enemies it sees, how easy/hard they are to kill, ect. This could lead the way to a bot that can truly learn about, and react to, its surroundings, rather than simply simulating the effect of it through simple forced mutation and adaptation a-la Fruitflies. It would also be good to do so in order to lay the groundwork for memory filetypes and a crude filesystem to be used in later bots. Some kind of interpreter working through a higher level language (I.E., Pybot) would be HIGHLY recommended. Even more so, working from conceptual ideas down through rough logic flowcharts through pseudocode and finally down to DB-DNA is highly recommended as well, if nothing more than to preserve order in the code itself and make sure it stays highly modular.
-
Awesome if you could get it to work. Im not sure how a file system would work or how a bot would utimatley use it. Would my tentacle cells be of any use? Their memory is mostly dead space anyways.
-
If anyone would care to try, it would be nice to see a proof-of-concept bot that would create and maintain "dead-weight" memory cells that it ties to and stores and retrieves data, such as veggie positions and densities over time, its health over time, what enemies it sees, how easy/hard they are to kill, ect.
It would be extra cool if you used veggies for this. Mark certain veggies as "seeds", and never eat them (mark certain memory locations probably. Maybe some of the outs). These "seed" veggies would act as seeds for local veggy colonies as well as signposts that bots could use to post locations for other "seeds" that presumably would have veggies starting to grow.
Sort of like posting maps to other oases in each oasis.
Not sure how efficient a strategy it would be, but it would be pretty cool. Especially if you set it up on a huge world, so the veggies are really far apart. And you had roving bands of animals that travel from seed to seed, feed on all veggies but the seed, and then travel on to the next seed. The animals could efficiently aim themselves at the nearest seed and then go completely dormant for however long it takes to get their (hundreds of cycles probably).
-
On the subject of file formats.
A 'file format', used in the context of bot based data storage, is the term that I would use to describe a system of creating different types of memories (files) and determining the beginning and end of a file, a date/time format, and how the data is stored. For example, all files have headers. Raw text files (.txt) have nearly no header, save for the beginning of the file. In a memory, a memory file would require a 'header'. A 'beginning of file' marker, a filetype marker, a date marker (or order of creation marker), and any other identifying details that it would require. Thinking about it a bit more, a bot would also have to make use of a file directory system to cut down on processor time and code required to locate files. Accessing things such as lists of 'seed' locations (to borrow your example of a potential application of such a system) will be difficult without loops, but I think it shouldn't be too terribly difficult to come up with something.
Also, tentacle cells. I don't think using them for memory is a great idea. Tentacle cells are often right out in the thick of it, exposed to attack and wayward virus/venom shots. Besides, the ties used to create the tentacle would be better used to transfer data between itself and its hub cell. Not to mention that the operation of a tentacle is already a data intensive operation.
-
I think the cells toward the center of the bot should be for long term storage and long term decision making (eg, what do i do with my life?), as well as transferring information between the other body parts. For example, if a swarm of veggies is detected moving north, then it should send info about it to the tentacles in the front asap to curl around and catch as many of them as possible. The cells on the outside like the tentacles are the ones that ultimately collect information about and manipulate the enviroment. These cells should store the "need to know now" information and distribute anything important back to the inside cells for long term storage. They have to have some kind of system for recieving/spreading instructions from the brain.
Once you have an "operating system" for the bots then you might be able to make some kind of higher level interpretor to program for it, kind of like you do for db code now. What kind of file types would there be for this "operating system". For one you have information about the enviroment, including tons of raw statistics and random facts. Then you might have more "proccessed" data that has averages and some rudimentary patterns in it. Then you might have some of the highly proccessed data which is just like the proccessed data but its done better with more patterns and stats. You also have to have instruction files for different bots which would carry instructions. These would somehow be created from the statistics files and distributed throughout the bot or at least to the cells that needed it. Any other ideas?
-
A lot of that requires extra memory. When you get down to it, you have to remember that each bot is restricted to less than 1000 spaces for individual pieces of data. Not to mention that you have to become much more specific if anything is to happen. I shall demonstrate;
A bot is developed with these traits, focusing on a central nervous system consisting of a brain with specialized thinking cells and many memory cells. For this example, we shall assume this organism is in its young/infantile stage, and has one processing cell and four memory cells, plus the three data bus cells required due to the three tie limit. The primary brain cell (henceforth referred to as the brain itself) is connected to the memory cells by the bus cells. It is connected by a single tie to the first data bus, which ties to the other two data buses. They tie to the remainder of the memory cells. The primary job of the data bus is to manage the cells connected to it and allocate data received, such as coordinates, info about a species encountered, etc. The bus cells themselves can allocate some memory to themselves, as well. Lets say the organism detects another bot (the method of how it accomplishes this can be ignored in this demonstration) and decides to store information about it. Gene length, body and energy levels, shell/poison/venom/slime levels, indications of other capabilities such as viruses, etc. It reads the data through its eyes or whatever it uses, and then sends the individual numbers to the data bus, along with the indication that this is a new data entry about a new species. The data bus then decides which cell is currently the least full (or alternatively it could allocate memory sequentially, filling one after another. In this manner, a full simulation of a computer could result, using a series of opcodes and reading programs from memory to form a ridiculously primitive and slow, though nonetheless incredible, CPU) and allocates the data to it. It saves the location and ID of this entry in its own directory. It may be a good idea for a bus to have its own storage for storing directory entries, at least for the first bus. But this would be better servd if it is possible to send data through multiple ties (more than three) reliably.
For example, if you were to use a safety margin of 500 usable memory locations per bot, and store data in integer form between 0-255, you are looking at two bots per kilobyte of data. This becomes very claustrophobic for a long term data storage system. Efficient management and allocation of information is an absolute necessity.
-
Bots can have more than 3 ties by the way. Im not sure what the use of a "data bus" would be. Why not just have a group of "brain cells" that would each store memory and do some proccessing each cycle. You might be right about the limited memory but bots don't really need that much memory and if you compress you can get even more. For example, You encounter bots without any slime/poison/shell/venom, etc. Just store a single negative number to mark that all of those were equal to zero.
-
True. The format still needs to be ironed out, with species entries possibly using only two or three memory locations, with the ID in plain ASCII numerals and data stored as binary, each bit corresponding to a capability, but there would still need to be even more memlocs used to account for saving the values for things like the average energy and body levels. And the purpose of a memory bus would be to, for the most part, take a huge load off of the central brain cells for memory related tasks, such as finding and storing memory entries. Locating a single data entry in a large memory bank if it was all attached at a single point would take hundreds of cycles. And since there are no loops in DB-DNA, it would require the use of sim cycles as the loop used for searching memory and building/searching through lists. In addition, searching through memory requires building lists and arrays to iterate through, and this requires scratchpad memory to be allocated to bus operations, further reducing storage, meaning even more cells must be used. And yeah, it will need TONS of memory space. Once you start adding up all the entries that it will possibly be entering, it starts to get HUGE.
Once you really begin to think about what it will take to get this kind of thing working, it becomes clear that this thing would in no way be a viable evosim or combat organism. Evosim, maybe. But if you include commands and opcodes to be interpreted and executed, mutation goes out the window. But it would be SO freaking worth it. I wouldn't be able to do ANY of the coding required in such a bot, but I can help figure out how to make the thing go. I have a lot of free time to ponder things. This concept has taken up a lot of my thinking time recently.
-
I want to see it work to. The dna would be huge, yes, but it would be mostly repetitive and structured, so once you figure out how it works you can piece together how it will work. I don't think the memory is the big issue here, its how it needs to use the memory. I think every cell should have an event it stores every cycle. This will include everything of importance that happened that cycle. It will keep several of these past cycles stored up. Every cycle it will make another one and, if theres no more room, probably delete one to. Every cycle it will look for important information thats being broadcasted and broadcast as much important things it knows as it can. This will require some kind of system for coordinating this mess. First you'll need a system for just making sure the bots are as aware of the other bots as possible and know whos reading from their touts and try to predict which bots touts it should be reading from. It can use the tloc/tval (im not sure thats the right sysvar but you get my point) to send a single piece of data to one other bot to, probably one that isn't actively reading from it. This will mostly be used to inform other cells that it has important information it needs to spread and they should read from them on the next cycle. Next you need a system of deciding whats important information and whats not. If a bot encouters a rare event, how important is the info it collected on the cycle before? How important is info collected from other bots on that cycle or previous cycles? This might have some flexibility in that over time bots can learn whats important and whats not, but in they still need some grand system for determining it. You can store the memory in the same manner. You'll need a system for creating "directories" which could be one way of organizing it. Bots would combine similiar pieces of information into a single more broader peice. They might be wrong alot but it would still be cool. Heres how you can compress a single value to store 5. Just take each value you want, divide them by 5, and put them in binary into a single memory location. Sure, it will be off by 5 because of the stupid rounding, but most important values can be off by much more than 5 before they become usless.
-
Sounds like a really good idea. If it helps, there's no tie limit...
Sorry I've been out so long. My old computer totally stopped working, and I've got a new mac to replace it. Sadly, I haven't gotten round to figuring out how to run DB yet, and my time will be limited this year anyways - I'm doing a full high school course, as well as several uni papers, and five scholarships (harder than both) on top, so it's pretty much non-stop for me. In addition, I'm trying to make a national sports team, which eats up the rest of my time. Bottom line, I'll check in every now and then, but don't expect many contributions.