Messages

76

Darwinbots3 / Bot DNA

« on: July 20, 2007, 12:17:30 PM »

I've just been thinking. . . Does it matter so much how we implement nested conditions? After all, mutations will almost never evolve conditions, much less complex/nested ones, and conditionals are often the first things to break. That is, unless you are planning a major overhaul in that respect, bots will break conditions, no matter how you nest 'em.

77

Darwinbots3 / Bot DNA

« on: July 19, 2007, 09:17:57 AM »

I fail to see how doubling the number of commands a mutated bot needs to successfully nest conditions would actually reduce problems. Seriously, if it's gotta put pushbool in the right place, and popbool in the right place, wouldn't it be easier just to put one closing-brace esque command in the right place? I mean, the code would work, but it seems like an awfully complicated system. I thought we were trying to make it simpler so that mutations could actually have a chance?

In short (kindof), it's a neat solution, but I don't see how it would improve from the more basic option. I'd think that it'd be less intuitive for humans and harder for evo-bots to develop.

78

Darwinbots3 / Bot DNA

« on: July 19, 2007, 06:22:40 AM »

Furthering the discussion on physical defenses or code defenses, code defenses does NOT necessarily mean illegibility. They can be as simple as zeroing things that you aren't using if your gene count goes up. Honestly, I agree. Stab the SG bots. However, code defenses really ought to stay. It would take a lot of ingenuity, for instance, to make a bot that could recognize when it had been turned by an info shot (maybe by storing how much it turned last turn into a free var and the same with last turn's orientation, and if it didn't fit right, turn back). Seriously, we should be promoting ingenuity, not demoting it. It's a lot more fun to see bots using complex behaviors to protect against things like this (especially since a lot of attacks specifically attack behaviors, ala info shots and viruses), then it is to just write 100 .mkslime store. Still, those are just my own (rather strong) viewpoints.

Custom labels would work, probably. You could also just make evobots name the codules from a list, which, could either as an easter egg be populated with joke names, or they could just be things like a, b, aa, etc. Either would honestly work, but defining codule names wouldn't allow any funny easter eggs in the game, would it?

Understanding your idea on the call stack makes a lot of sense, now. I agree with that approach (Why do I feel like I'm being converted, somehow?).

You also mentioned that nested conditions could be done without ending braces. The only way I can think of this would be having ridiculous numbers of codules pointing at each other, each representing one condition. Kinda like programming nested if-then-elses on my TI-83: you can do it, but only if you jury-rig it with a boatload of goto commands.

In terms of pop and push commands for recalling old stacks... It'd have to entirely repopulate the stack multiple times in one cycle for each and every bot if someone wrote something that called the pop command multiple times. I don't know if this would be a major performance hit, but even a small one, with enough bots doing it, would be kinda awful.

79

DNA - General / Rounding

« on: July 19, 2007, 12:01:55 AM »

Just edit the console so that we can run math commands, like 30 50 add would output 80. Would also be nice for debugging a bot, since we could do it in the game.

80

Darwinbots3 / Bot DNA

« on: July 19, 2007, 12:00:26 AM »

We could totally program in evobots a series of possible codule names. Would be hilarious.

Like:
cond
start
call Darwinbots_Awesome_>
stop

It would crack me up if I saw evobots naming codules like that.

81

Darwinbots3 / Bot DNA

« on: July 18, 2007, 08:43:32 AM »

Insta-fizzing anything that is already in the call stack isn't that useful. What if I need to run a formula at multiple points of a bot's code? If I only needed it once, then I could just copy and paste it in.

Alright, then, for multi-threading. Just for viruses and modeling, then.

I see what you mean by closing braces screwing up in mutations, but there isn't much of a choice if you want nested conditions. Besides, if messin' with the closing bracket is a deleterious mutation, the bot will likely die soon, and it wouldn't really matter.

As a side note, does the fact that you wrote the codule names in your example as text instead of numbers mean we will likely get to name our codules? Pretty pweases?

82

Darwinbots3 / Bot DNA

« on: July 18, 2007, 01:54:43 AM »

I'm not entirely sure how expensive you could make it. After all, with venom or info shots, I can force you to give me energy. Then I can use energy shots to feed. Then I can use body shots to feed. That's feeding three times as fast. How much are you thinkin' in terms of costs for shooting? It'd have to be exponential, because otherwise tieing would be the only real way to eat (or just biting their head off, if you're large enough).

I could see control being returned to the root after every codule is completed, so long as it returns to the position that codule is called. It wouldn't be very powerful, but I could deal with it. Mostly would just need a lot more conditions and gotos in the root gene and less in other places. Not my particular style, but it would work either way.

One way, of course, would be to combine the two options. Allow gotos, and after the codule called was completed, it would return to the codule that called it the line after the goto. Then, after that codule had completed, if it was called by the root, then the root would call it back.

So it would work like:
Root -> Codule1 -> Codule2 -> Codule3
Then, after codule three had completed:
Codule3 -> Codule2 -> Codule1 -> Root
(each codule being given a chance to finish before returning to the one that called it). Anyways, just my opinion.

This is what you are thinking of, correct? If so, then I'd say we are now in agreement as to how codule calling should work.

With multi-threading, I still see little use to it, and if it were me, wouldn't bother programming it. Still, at least I can not use it should I want to. I am curious as what applications for multi-threading you were thinking of people using.

Oh, and a bit earlier, I believe you mentioned something like "code defenses shouldn't be as useful, and should be replaced with better physical defenses". I don't remember the exact words, and I'm too lazy to look it up. I strongly disagree here. I should be able to place a superiorly coded bot into a sim and watch it win, even if the other, worse bots have built up significant amounts of slime, shell, etc. Essentially, code defenses don't cost much (only a store), but they only protect against 1 or 2 very specific things. However, if you just wanted a more generic defense, say, against all info shots, you could add in some shell or poison or whatever it is. If you wanted a specific defense against, say, Icarus' turning shot, then you could implement some code to protect against that.

In terms of preventing ridiculous numbers of loops, you could set it so that if a bot executes a single codule a certain large number of times in one cycle (1000? Larger?) then either that specific codule could be deleted, the codules that called it could be deleted, or the bot could be killed. I don't know which.

Your example of in-gene conditions (*.eye5 0 > *.refeye *.myeye = and 314 .aimdx store else *.revelup .up store) has some pluses and minuses. First of all, I like the ands and elses (and presumably elseifs, xors, ors, etc.) However, this assumes that after the last else you always want to stop at a store (or maybe it's the end of a line, but then you are making different forms of whitespace different, which is a big no-no. Like MUMPS. Bad, making whitespace different than whitespace). What if I just want to perform stack manipulations? Or if I want to perform multiple stores? We really need some sort of an operator that says "Stop checkin' this condition/this else." Else would also act as a condstop. Or are you assuming that it should follow the above condition until a new one is instated? That makes nesting impossible, however.

Essentially, I'd like it something like the following:
*.eye5 0 > *.refeye *.myeye != and 50 -1 shoot else *.eye5 0 > *.refeye *.myeye = 20 .aimdx store *.eye5 30 > 30 .dn store condstop condstop

And here's the same thing commented:
*.eye5 0 > *.refeye *.myeye != and 'Checks that both eye5 is greater than 0 and that you aren't one of me.
50 -1 shoot 'Shoots an energy shot with a shootval of 50.
else 'Ends the previous condition, checks a new one that is equal to NOT the previous condition.
*.eye5 0 > *.refeye *.myeye = and 'If eye5 is greater than zero and you are one of me.
20 .aimdx store 'Turn.
*.eye5 30 > 'A nested condition. Activates if the else is true and eye5 is greater than 30.
30 .dn store 'Goes in reverse.
condstop 'Tells the nested condition that it's over.
condstop 'Tells the else condition that it's over.

Anyone reading this, please contribute to the discussion. Please. I think we probably need more than two or three people's inputs on such a radical and important change.

83

Newbie / Help !!!

« on: July 17, 2007, 08:46:59 PM »

If anything, we need more jokes. Maybe we should add a sysvar that allows a bot to see if it was dead last cycle? Hmm...

84

Darwinbots3 / Bot DNA

« on: July 17, 2007, 05:44:51 AM »

I humbly ask that you read this ridiculously long post.

Alright. Now understanding the general plan for multithreading, I'd be willing to go with it. No objections there.

Ultimately, for conditions, I'd like a multi-tiered system. At the top, we'd have root codules that would be executed every cycle. In those would be simple genes that called other codules. Thus, root codules to standard codules. Standard codules could and should link to a multitude of other standard codules. Then, in codules, genes should still have the "cond" statement to allow conditions to apply to all operations in that gene. Then, you could have conditions attached to each statement, like "*.nrg 1500 > 50 .repro store". One tricky bit would be deciding when the condition section ended, since we can't assume it ends at a store (some genes merely add values to the stack to be processed later). Perhaps a "condstop" operator could be used, of some sort, inside of the start/stop section of a gene. Essentially, it would look like "*.nrg 1500 > 50 .repro store condstop". That would also mean that you could attach non-stores to conditions without creating lots of genes, like "*.eye5 0 > 50 mult condstop", which would multiply the top stack value by 50 and place that on the stack, if eye5 say something. It would also allow for easy nested conditionals, as the condstop could encompass multiple lines, if needed.

Alright. The above method would certainly allow quite a bit of SG-ifying, but SG-ifying wouldn't really make the bot better in any way (you are still spending energy on condition checking, and viruses are probably receiving an overhaul, so I doubt .delgene inc .delgene inc will really be valid.)

I suppose the thing preventing threads from interacting with each other until they had already finished would prevent the racing condition problem.

To deal with shots, change .shoot to a universal shoot command. It would take the first to values on the stack to determine what kind of shot it was, and the second value to determine it's shootval. Essentially, shoot wouldn't need a store anymore. So a energy feeding shot with a shootval of 50 would be "50 -1 shoot". We'd probably have to do the same thing with quite a few other variables, and turn things into commands. Store, obviously, would still remain, for usage in any variables that don't support the command-ized form, or for free variables to store information. For multi-threading, perhaps we could do some sort of randomization for ones that don't mix well (so if codule1 tried to use an energy shot and codule2 tried to use a body shot, it would randomly choose one. Variables/commands that are more easily averaged (like up) could simply be averaged.

While we're speaking of new commands, try to include some basic trig functions (for fancy aiming), logarithmic functions (for calculating how much damage shots should do), and any other obscure ones you can think of that I have missed. Also, even if things like refxpos and refypos are relative to your own bot, you should be able to calculate angle from different locations (still relative to your own bot, once again, for aiming).

I still think that raw gotos and gotosubs are essential. Say, if I've got a function that determines how much I should power up a shot. Perhaps a multi-gene one. I can't exactly wait until the end of the shooting gene/codule is over before I call that function. We could always disable these in mutations, and have a third command that would goto as soon as the gene/codule finished. Maybe gotoafter?

How will a bot react when it finishes a codule that has no goto commands? Will it automatically continue on to the next codule, or will it just end the program then? In theory, if the former is true, then could you end DNA execution early by creating a blank codule at the end of the DNA and call that?

With the whole vector vs. integer thing, allow both. Sometimes, for instance, to prevent orbiting, you solely want a certain direction (like *.veldx -1 mult .dx store), or when you only want to accelerate towards a bot in one direction, and only match it's sideways velocity. A lot of the time, it would be a lot faster and easier just to use it as a vector, however.

Erm, yes, I think I'm done rambling. For now.

Edit: I'm not done rambling!

If you split the .shoot into a plethora of things like .vshoot .wasteshoot .nrgshoot, .medicshoot, .infoshoot, .venomsoot, and .bodyshoot, what mechanism would be implemented to prevent me from firing every single one of them in one cycle? Essentially, bots could start throwing everything but the kitchen sink at their target and would no longer have to strategically decide which is better at a certain time.

85

F1 bots / Reaper (F1)(Googlyeyesultra)-17.07.07

« on: July 17, 2007, 01:18:50 AM »

Alrighty! This one is a little better than Rabidus 1.1, but it still won't beat Etch. Feel free to replace all versions of Rabidus with Reaper.

Code: [Select]

'Reaper: A bot by googlyeyesultra.
'Almost identical to my other bot, Rabidus, but a bit harder to beat.
'To the reaper, every foe is a stalk of grain.

cond
start
'Conspec, Self-Virus Protection, Set Eyewidth
*.myeye *.myshoot add *.myup add 998 *.robage sgn 1 sub -1 mult mult store
65 999 *.robage sgn 1 sub -1 mult mult store
1221 .eye5width *.robage sgn 1 sub -1 mult mult store

'Targeting/Movement
*.refxpos *.refypos angle .setaim
*.eye5 sqr dup div
*997 *998 sub dup div mult mult store

*.refveldx *.veldx sub .dx
*.eye5 sqr dup div
*997 *998 sub dup div mult mult store

*.refxpos *.refypos dist 2 div *.refvelup add *.velup sub .up
*.eye5 sqr dup div
*997 *998 sub dup div mult mult store

'Sharefeed if multi
99 .sharenrg *.multi mult store
.sharewaste *.multi mult inc
stop

'Reproduce
cond
*.nrg 850 >
*.body 50 >=
start
100 .strbody store
49 .repro store
stop

'Conspec
cond
*.refeye *.refshoot add *.refup add *.refshell add *997 !=
start
*.refeye *.refshoot add *.refup add *.refshell add 997 store
stop

'Birthie cut
cond
*.robage 2 <
start
.tie *.robage -1 mult 1 add mult inc
.deltie inc
stop

'Spread out when born
cond
*.eye5 0 !=
*997 *998 =
*.robage 20 <
*.robage 2 >
start
*.refxpos *.refypos angle 628 add .setaim store
*.eye5 .up store
stop

'Spread out later
cond
*.eye5 0 !=
*997 *998 =
*.robage 20 >=
*.numties 0 =
start
*.refxpos *.refypos angle 628 add .setaim store
*.eye5 2 div .up store
stop

'Shoot feed
cond
*.eye5 30 >
*997 *998 !=
*.refpoison *.refshell >=
start
-6 .shoot store
stop

cond
*.eye5 30 >
*997 *998 !=
*.refpoison *.refshell <
start
-1 .shoot store
stop

'Making venom
cond
*.nrg 300 >
*.body 40 >
*.nrg 2 div 100 75 *.venom sub >
start
75 *.venom sub .strvenom store
stop

'Firing venom
cond
*.eye5 30 >
*997 *998 !=
*997 0 !=
*.venom 25 >
*.robage 10 sub *990 >
start
.setaim .vloc store
*.aim .venval store
*.venom 25 sub rnd 25 add .shootval store
-3 .shoot store
*.robage 990 store
stop

'Info shots
cond
*.eye5 30 >
*997 *998 !=
*997 0 !=
*.robage 4 sub *989 >
start
31999 .shootval store
.mkslime .shoot store
*.robage 989 store
stop

'Deltie enemy ties/conspec ties
cond
*.numties 0 >
*.tiepres *996 !=
*.trefshoot *.trefeye add *.trefup add *998 = or
start
*.tiepres .deltie store
stop

'Tie
cond
*.eye5 30 >
*997 *998 !=
*.numties 0 =
start
999 rnd 996 store
*996 .tie store
stop

'Tiefeed/Counter leach
cond
*.numties 0 >
*.trefshoot *.trefeye add *.trefup add *998 !=
start
*996 .tienum store
*.tieval sgn .tieloc store
-1000 .tieval store
stop

'Body to Energy Conversion
cond
*.nrg 850 <
*.body 50 >
start
*.body 10 sub 100 ceil 10 mult .fdbody store
stop

'Energy to Body Conversion
cond
*.nrg 250 >
*.body 50 <
start
*.body 30 sub 100 ceil .strbody store
stop

'Waste Removal
cond
*.waste 100 >=
start
-4 .shoot store
*.waste .shootval store
stop

'Shoot Virii
cond
*.eye5 15 >
*.nrg 150 >
*.vtimer 1 =
start
50 .vshoot store
stop

'Make Virii
cond
*.vtimer 0 =
start
*.thisgene 1 add .mkvirus store
stop

'Virus
cond
65 *999 !=
start
*.thisgene .mkvirus store
*.myeye *.myshoot add *.myup add 31999 mult 50 floor .vshoot store
.delgene dec
stop

'Chameleon genes
cond
*.in1 0 !=
*.in1 *.out1 !=
start
*.in1 .out1 store
stop

cond
*.in2 0 !=
*.in2 *.out2 !=
start
*.in2 .out2 store
stop

'Some various code defenses
cond
*.fixed 0 !=
start
0 .fixpos store
stop

cond
*.delgene 0 !=
start
0 .delgene store
stop

cond
*.shoot -2 =
start
0 .shoot store
stop

cond
*.mrepro 0 !=
start
0 .mrepro store
stop

cond
*.sexrepro 0 !=
start
0 .sexrepro store
stop

cond
*.repro 49 !=
*.repro 0 !=
start
0 .repro store
stop

'End of Program
end


86

Darwinbots3 / Bot DNA

« on: July 17, 2007, 12:30:09 AM »

So if I didn't want the multi-threading features, I could just use one root with a lot of branches?

87

Darwinbots3 / Bot DNA

« on: July 16, 2007, 11:08:19 PM »

Would this be a seperate command from goto and codules? If so, no further objections. I could live with it, and maybe use it from time to time. Still, having no ability to not use multi-threading when it doesn't serve a purpose well would be quite annoying.

88

Darwinbots3 / Bot DNA

« on: July 16, 2007, 10:54:37 PM »

I still don't like multi-threads. Can you imagine how hard it would be to debug a bot in? Not only would you have to check the last gene that had activated that referenced the misbehaving variable, but every single one that activated and referenced it (which, in large bots, could be a ridiculous amount). Does that also mean that 30 .repro store 70 .repro store will make 50 .repro store, even if done in one gene?

89

Darwinbots3 / Bot DNA

« on: July 16, 2007, 07:24:35 AM »

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.

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.

90

DNA - General / Swapping the top two stack values?

« on: July 16, 2007, 01:07:52 AM »

Trust me, guardian WILL slow your sim to destruction. One of 'em will bring it down to around 2 cycles per second, and more will put it down to less than one.

I think you've developed a new strategy: Make the game lag enough that no one in their right mind would watch your bot to figure out how it works, and make the code complicated enough that no one cares to decipher it.

For now, I think your PyBot idea is great. However, once we get elseifs, nested conditionals, gotos, and a few other commands, I think it'll be far less useful. After all, you can then code in the defines manually once we get 'em.

Commendations on your amazingly powerful bot. Methinks I'll be bumped to third.