There are five types of mutation. A point mutation changes a single byte in the organism. An insertion inserts one or more bytes. A deletion deletes one or more bytes. A transposition takes two contiguous chunks and swaps them. A duplication takes a chunk of bytes and inserts a copy immediately afterwards. Mutations can take place anywhere within the organism.

Of course, as you observed, we expect most of the progress to occur at the “tail”, where the tail is the part of the solution after the last time a virus was eliminated. Changes here can’t make performance any worse, but could make it better. A mutation earlier on is more likely to throw everything behind it out of whack, since the later moves will be played when the game is in a different state. It’s possible to make a good beginning even better, but it’s less likely than improving the tail.

*thinking*

ok, i agree that the “top n solutions” selection technique may not be optimal for Dr. Mario, but for other game-types i would still believe that it would be superior… i.e. Mario Bros…

the next thing i have to say really depends on how your mutation subroutine works, but i assume that it simply randomly identifies a “move” and mutates it…

given the nature of video games, do you think it would be beneficial to include more than the combinations and mutations? by that, i mean to simply take solution “L” (that has obviously already been selected to contribute to the next generation) and simply “amputate” a random length of the solution tail? in order to allow it to participate in the fitness evaluations you’d have to randomly generate (a la generation 0) a new tail, though it really shouldn’t be that hard to actually implement given that i assume you have the subroutines for these already in your combinations and as part of your initial population generation, respectively…

just to make sure i’m making sense, it would be like if you had solution “a,b,b,u,d,l,l,l,r,d” and instead of mutating it at the fourth ‘move’ of ‘u’, “amputating” it at, say, the first ‘d’ and regenerating a new tail…

the only reason i bring this up is that since video games, especially old school Nintendo ones, are fairly linear in their gameplay, and you may get stuck with solutions that, while ‘best’, just aren’t going to get you there… and while this is typically picked up by mutations, well… like i said, i don’t know how your mutations work so i can’t really speculate…

all in all, though, looks good… and is pretty impressive…

oh, and by the by, it’s about time you excluded start/select…

So assuming you can crunch through 8 generations per day, 100 generations will take a little under two weeks, and 100,000 will take a bit over 34 years.

(These numbers are reasonably valid for a 1.7 GHz Pentium M; a faster processor would do better.)

I haven’t done any real work trying to optimize the code, but I strongly suspect most of the time is being spent in the emulator itself, so even streamlining my additions to the codebase probably wouldn’t shave off much time. (Then again, humans are notoriously bad at optimizing code through intuition.) Parallelism is one potential alternative to crunching through more solutions in less time, but that’s a topic for another post….

But seriously awesome-sauce Paul