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].