Code center > Suggestions

A Few Suggestions

(1/3) > >>

Aeolus:
Judging by the fact that I don't post on here often, you can tell I'm not the best bot programmer. I tend to run evolution sims most of all, and I've thought up a number of things that I thought would help people such as myself.

1. More Scripts
Specifically, the ability to add a robot, the conditions of so many cycles passing, or a certain robot's population reaching a specific height would all be helpful.

2. Fewer Sysvars
One thing I've noticed is because of bot programming, many many sysvars have been created. Unfortunately, this upsets the balance of evolution and the probability of getting the right sysvar in the right place. With each new version, it seems harder and harder for robots to evolve. Some solutions to this are getting rid of some sysvars, making certain sysvars more likely to be added to a bot, and most drastic of all, splitting DB into two versions: Evolution Intensive and Program Intensive.

3. Randomization Features
Currently, the only setting that can mutate are mutation settings. Don't get me wrong, that's a great thing, but in order to evolve a bot capable of surviving in a wide variety of conditions, you have to change the conditions. A randomization feature for nearly all settings would be needed, and the ability to turn of randomization for each setting as well. I don't expect this to happen any time soon, or even in the next versions, but it would be one of the best tools for evolving bots.

Thought these ideas may seem drastic and difficult, I feel that something needs to change in order to keep the Darwin in Darwinbots.

Numsgil:
1. I agree. I would eventually like to see some scripts available. Perhaps Lua (since it follows VB fairly closely in syntax).

2. This depends a great deal on what version you're referring to. Prior to 2.4 the program chose new sysvars or sysvars to change based on current sysvars. That is, .aimdx would mutate into .nrg or some other sysvar, and never (well, rarely) into 697, or some other "empty" memory location. The fewer sysvars there are the more likely any sysvar is to be selected.

2.4 just chooses numbers between 1 and 1000, which means any sysvar has a 1 in 1000 chance of being selected.

I'll freely admit the memory location to action system is the weak link in the mutation process. The stack works brilliantly for mutations. Since every command reads from or writes to the stack, mutated commands are quite likely to do (or not do) something new.

That said, from a reality standpoint, real organisms aren't terribly good at comming up with novel genomic code either. Most mutations in the animal/plant/fungal/protist world modify instead of create.

I think perhaps the best solution is to increase the domain of acceptable input for as many sysvars as possible. For instance, in the C++ version I'm moding shots be 10 if they're negative and 1000 if they're positive, so almost all values do something if they're stored in .shoot.

That doesn't fix the problem of finding the right sysvar, but it does soothe the issue of using a novel sysvar.

We could half the sysvars. Have 500, or even 250, instead of 1000. With tie commands replacing dozens of tie commands, the new sysvar list is looking rather sparse. And several read and write commands could be combined into one read/write command (.fix and .fixed for instance). That would probably help selecting sysvars, but it's still rather drastic.

3. This would probably be combined into scripts. Depending on how scripts are implemented you could end up with total control of program flow and settings.
------------------------------------------------
Drastic ideas are good, they help shake up the status quo.

EricL:
I agree with the thrust of the discussion here.  Here are a couple of steps in that direction:

2.42.6 will be out this week.

2.42.6 mods shot values as Num's describes except that negative shots are essentially mod 7 (it's a tad more complicated than this, but you get the idea).  So, beginning in 2.42.6, each and every possible value that can be placed into .shootval (except 0) will map to some morphological action.  In subsquent releases, I will be walking through other sysvars and as Nums says, similarly expanding the domain of possible inputs so that every mutation does something.  Suggestions here very welcome.  There is a reason biological DNA codons are degenerate....

Additionally, 2.42.6 has some fancy dynamic features which can modify incoming energy levels based upon total sim energy and change costs dynamically and automatically over time as a function of bot population.  Such features are focused squarely on evo sims where for example, you want costs to be low or even zero early in the sim, say before evolving a replicator or the ability to feed, but want to raise the selection pressure over time as bots evolve and become more effecient.

Personally, I'm mostly an evo sim guy, so while I'll take feature requests from anybody, most of the new work I'm doing on the 2.4 fork besides fixing bugs is focused squarely on evo sims.   You will probably see loci-specific mutations rates (visable to mutation and selection) for example within a month or so.

Numsgil:
If you check out the "source snapshot" I released a while ago, it contains a read me for sysvar changes I made in the C++ version.  That would be a good start as far as finding some ideas for changes to various sysvars.

Numsgil:
Been thinking about it, and this is my current thought:

Instead of sysvars and memory locations written to and from, have everything be a command, with current state information stored in a hidden Finite State Machine.

Sort of like how OpenGL works.

Sysvar commands would be either read or write. Read commands return information and place it on the stack. Write commands take information from the stack and directly push it into action.

Basically commands would either be input, output, or manipulation.

Alot of sysvars could be condensed or entirely modified. Shots, for instance, could be segregated into nrgShot, bodyShot, etc., removing the need for keeping track of -1, -6, etc. The parameter pased could then be the shot strength, what shootval is currently being used for for -1 and -6 shots. Up, dn, dx, and sx might  be combined into a single command that takes a vector (basically removes an (x, y) pair from the stack).

Here's animal minimalis rewritten in what I would see such a language being:
 
 bang = vector movement command I was talking about above.  It's also additive in this example (shvarz suggested this once, and I think in this example it works):


--- Code: ---'Good for mutation sims and for newbies to see how a basic bot works.
'Contains everything necessary for it to survive and reproduce.

cond
5 eye 0 >
refeye myeye !=
start
refvel bang
 0 30 bang
 stop
 
cond
5 eye 50 >
refeye myeye !=
start
0 nrgshoot 'default strength energy shot
 0 -30 bang 'erase the added 30 velocity if we get too close
stop

cond
5 eye 0 =
refeye myeye = or
start
314 rnd turnright
stop

cond
nrg 20000 >
start
10 repro
stop
--- End code ---

 Obviously alot of work would be needed to go through each and every sysvar and command and try and sort a clear and coherant language from it.  Special care would need to be taken with sysvar names I think.  Alot of them are currently a little obtuse.
 
 We'd probably need to create a kind of ARB to design the language, again similar to how OpenGL operates.  And, while I'm on topic, a way for users to create their own "extensions" would be nice, but I'm not sure how something like that might work.
 
 It plays to the strengths of evolution as I understand it from playing around with Darwinbots.  Random mutation is absolutely terrible at finding a single specific value needed for a specific action.  Most interesting mutations I've seen have been from the DNA manipulating the stack in a new way, and less from finding a new place to store data.
 
 Incredibly drastic suggestion, so I'm not really endorsing it yet.  Just brainstorming.

Navigation

[0] Message Index

[#] Next page