Small Corewar Evolvers

Evolving warriors for Corewar doesn't have to require large complex programs, here are some that manage using less than 5Kbytes of source code. Sometimes much less.

Although small these are real evolvers, TEV, JB and SEWAX have made nano warriors that placed on the SAL nano hill, and LCE can output 88-rules code and generate (weak but not too bad for purely evolved) papers for coresize 8000. For comparison - TEV12 is only 1.2K but can evolve to a benchmark like the much larger YACE; LCE is 4.2K but works as well as (or maybe better than) REBS (30K) and Fizzle (20K); JB is 1.9K or 4.8K depending on the version and my first try with it on the nano hill was much better than my first attempts with RedMixer (58K). SEWAX is a 4.7K evolver that combines unguided and bench-driven methods, with the right bench set it can produce nano warriors that are quite strong despite its lack of the fancier mutation techniques used by some other evolvers. SEVO is just 1.7K but includes some fairly advanced features like separately evolving the instruction modifier, line swap, delete and duplicate operations, both random and increment/decrement number modifications, and separate chances for each type of mutation.

The reason these evolvers are so small is for the most part all they do is evolve. Most of the code in large evolvers doesn't have much to do with actual evolving but with housekeeping stuff like reading and validating a formatted INI file, fancy interfaces, tracking information in the warrior comments, etc - just properly validating the settings can be more code than the evolving engine. Leaving most or all of that stuff out permits concentrating just on the process of evolution and makes it easier to try new things without editing masses of affected code. The things that are discovered can be applied to existing or new evolvers but it's nice to be able to work out the techniques in a small format first for once the INI format and internal structure is in place it's difficult to shift gears. Some of the techniques might be fairly easy to apply to existing evolvers, such as the indirect guidance method used by SEWAX which is applied around rather than inside the evolving code.

This section was last updated 12/19/11.

Evolving Techniques

Evolving warriors is a CPU-intensive operation, typically it takes many hours to days for each run. Make sure the computer can take 100% CPU usage for extended periods of time without issues. A good test is run "10 GOTO 10" in Blassic, QBasic etc, if the computer can't run a simple loop for extended periods of time then it's not suitable for evolving. File-based evolvers (such as the ones on this page) write to files constantly, don't run them on a solid-state disk like in some netbooks or a thumbdrive. On modern Windows and Linux systems usually the majority of the disk activity stays in the cache, evolvers that use a memory-based soup (TEV, JB, SEWAX) hardly flicker the drive light but officially I recommend evolving on a ram disk or a disk separate from the operating system. Notes about setting up a ram disk are in the RedMixer docs.

To effectively evolve one needs to be able to examine, simulate and benchmark the resulting warriors. Also if new to this sort of stuff phrases like "on the path" might not parse, so I wrote up a page about Setting up a Corewar Environment that explains how to make a path directory, batch files for running pmarsv etc. Of course the described methods are but one way to do it, old-timers do it with a dos prompt. Some evolvers (JB, LCE etc) save the soup as individual warriors and have no built-in system for rating them, so some kind of bulk benchmarking program is needed to test every warrior against a benchmark set to find the strong ones. I use my own TEST, it's a dos program but I run it under Linux using the DosEmu emulator running FreeDos, using symlinks I can CD to where I need to run it (including my ramdisk) then enter "test", it saves an INI in each directory it's run in so usually I just rerun the previous setup. Eventually I need to come up with a more cross-platform solution (maybe using Blassic) but for now it works. [I added a link for a Blassic warrior tester I originally made for Maezumo, now I need something to test single warriors and chart performance against the individual test warriors, like my old test batch]

Some evolvers (TEV, SEWAX etc) have built-in automatic benchmarking which mostly eliminates the need to do bulk benchmarks, benchmarking the output warriors one at a time is sufficient. Neither TEV nor SEWAX save the soup to individual files unless code is added. TEV updates a single file that contains the warrior with the highest score. SEWAX can save the entire soup to a single file for restarting and examining (another program would be needed to turn into individual warriors), while evolving it saves all new top-scoring warriors with bench scores more than a certain amount but usually that's only a dozen or two warriors for a typical run. When benchmark scores are used to drive evolution there is a tendency for the evolved warriors to "focus" on the provided benchmark set but not score as high on other benchmarks. Careful selection of the benchmark warriors can help minimize this effect, I've been using SEWAX to experiment with switching benchmarks mid-run, first generating strong warriors with say Koenigstuhl warriors then switching to the NanoBM07 test set. This tends to drive the previous bench results down but seems to result in somewhat more robust warriors. A similar technique can be done using TEV by adding save and restart code. Using a large composite benchmark set is another possibility. Evolving is a random process, what works for one session might not work for another so if it's not working out try again, if it still doesn't produce good results try a different bench set and/or monkey with the parameters.

Unguided evolvers (LCE, JB, SEWAX with re-insertion disabled and most of my other evolvers) tend to produce (nano) warriors that are naturally strong against multiple test sets, however the evolving parameters are more critical. A given set of parameters and starting conditions tends to produce warriors that rise to a certain strength then oscillate around that point (which may be different from run to run), there is no incentive for the evolver to produce code that pleases humans so it has to be tricked into making good code by careful adjustment of the instruction mix, battle selection scheme, mutation rates etc. It takes longer and requires a larger soup to produce strong warriors (and often doesn't happen and the run has to be started over), but they tend to be more robust and when submitted to a hill (assuming they place well to begin with) they tend to retain their placement better than guided warriors when the hill contents change. This isn't a hard and fast rule, just an observation. One avenue of research is trying to figure out how to increase scores through guidance without causing a focusing effect... a possible way to improve things might be to alternate between two different benchmark sets while evolving, haven't tried but sounds like an interesting experiment (maintain multiple high scores, one for each test set).

This section was last updated 6/23/09 [comment added 8/22/09].