Code center > Darwinbots3
Bot DNA
googlyeyesultra:
So if I didn't want the multi-threading features, I could just use one root with a lot of branches?
Martian:
Why not make store take 3 values and only work when there is a non zero value on the stack.
And change >, <, = etc. to take two values and place 1 on the stack if the condition is true and 0 if it isn't. Like the mult operator.
Then
--- Code: ---50 .repro *.nrg 5000 > store
--- End code ---
would work.
Numsgil:
--- Quote from: googlyeyesultra ---So if I didn't want the multi-threading features, I could just use one root with a lot of branches?
--- End quote ---
Right
--- Quote ---Why not make store take 3 values and only work when there is a non zero value on the stack.
And change >, <, = etc. to take two values and place 1 on the stack if the condition is true and 0 if it isn't. Like the mult operator.
Then CODE50 .repro *.nrg 5000 > store
--- End quote ---
But then wouldn't it be difficult to have a single condition control multiple store statements?
Martian:
--- Quote from: Numsgil ---But then wouldn't it be difficult to have a single condition control multiple store statements?
--- End quote ---
I was thinking that we could have this and genes.
--- Code: ---cond
*.eye5 25 >
*.refeye *.myeye !=
*.refpoison *.refshell =>
start
16 .shootval store
-6 .shoot store
stop
cond
*.eye5 25 >
*.refeye *.myeye !=
*.refpoison *.refshell <
start
16 .shootval store
-1 .shoot store
stop
--- End code ---
would become
--- Code: ---cond
*.eye5 25 >
*.refeye *.myeye !=
start
16 .shootval store
-6 .shoot .*.refpoison *.refshell => store
-1 .shoot *.refpoison *.refshell < store
stop
--- End code ---
Which is a lot more readable. It would also make Single Gene bots less complicated. But then we should leave the bitwise operators.
For example
--- Code: ---cond
*.eye5 30 >
start
-1
.shoot
*.memval -2 =
*.refeye 0 = |
store 'Shoot if the bot is hit with venom or if its a veggie (Checking with .memloc, .memval)
stop
--- End code ---
Which would be a good use for bitwise operators.
googlyeyesultra:
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version