  
Redmaker - a program that evolves warriors for "Corewar"
========================================================

Current version 2.91 file stats...
REDMAKER.BAS        54,508  12-27-04 12:09p
REDMAKER.EXE        77,423  12-27-04 12:09p

This program is distributed under the provisions of the
FSF/GNU General Public License, (c) 1998-2004 Terry Newton.
See: http://www.fsf.org/licenses/gpl.html

------

Corewar is a game where simple programs written in a language
called "Redcode" battle each other for points in a simulated
computer, originally called "Mars". A program dies when it tries
to run a DAT instruction or a divide by 0, the last running
program wins. If multiple programs are running when the timer
runs out, ties are declared. Typically battles are run one-on-one
with 3 points per win and 1 point per tie. Each battle consists
of many rounds with the warriors starting at different positions.
The final score is normalised to range from 0 to 300.

On the web, go to http://www.koth.org/ for pMARS software
and more about the game of corewar.

For Windows 95 I'm using the 32 bit version of pmars.exe
and the 286 version of pmarsv.exe (the 386 version doesn't
run in graphics mode under Windows). On my page if you need:
http://www.infionline.net/~wtnewton/corewar/pmars08.zip
http://www.infionline.net/~wtnewton/corewar/pmars286.zip

For Windows XP I'm using the SDL_pMARS package available at:
http://www.cs.helsinki.fi/u/jpihlaja/cw/pmars-sdl/index.html
Rename pmars-server.exe to pmars.exe and pmarsw.exe to pmarsv.exe,
and/or adjust the command line parameters using the P menus.

For Linux/DosEmu/FreeDos I'm using the old 386 pmars.exe and
pmarsv.exe from the pmars08.zip file. Requires at least FreeDos
beta 9, not DosEmu's built-in shell. See 2.91 notes for config.

The latest Redmaker version and info can be found at:
http://www.infionline.net/~wtnewton/corewar/evol/

This is a MsDos program, written in QBasic and compiled with
FirstBasic. Requires the dos versions of PMARS and PMARSV in
a path directory or in the same directory as Redmaker. If you
have qbasic.exe installed you can run the redmaker.bas file
if you wish.

This program creates and uses lots of files, running on a
typical hard drive it might consume 2 megs or more so make
sure there is sufficient drive space. It is much better to run
RedMaker from a ram-drive to save disk wear and to greatly
improve performance. A 512K ram-drive is usually large enough
(smaller cluster size), a typical config.sys line would be:

   DEVICEHIGH=C:\WINDOWS\RAMDRIVE.SYS 512 512 512 /E

Adjust the C:\WINDOWS directory name to reflect the actual
location of the ramdrive.sys file.

Redmaker creates warriors using the principles of natural
selection and mutation. Good changes survive and thrive, bad
changes die off. Crossover is not supported, so it's not exactly
a faithful model of evolution. Spatially, Redmaker arranges the
warriors in a two-dimensional grid, using letter pairs to
identify the warrior family, an idea I got from George Lebl's
SYSTEM evolver written in Perl.

Redcode has no limitations on instruction combinations, so
even totally random code is valid. Maybe not effective but
have to start somewhere. By battling neighboring warriors,
keeping the winners and mutating to fill empty space, the
warriors become more and more effective, first against each
other, eventually becoming strong enough to beat a few
human-written warriors.

Evolution can be left to proceed at it's own pace, producing
working warriors after thousands of generations although
sometimes uninteresting "plantlife" becomes the dominant
form. To force evolution along, new warriors can be required
to beat another warrior before being allowed into the world.
This guarantees that the code at least works. Redmaker allows
testing of starting code, new births, or both. When testing
new births with an untested start, testing is delayed to
allow some working code to naturally evolve.

Many variables guide the evolution process, change rate,
survival score, more than I care to document at the moment,
especially since I'm unsure of the correct values (why they
are variable...). I think I've got it error-checked enough
so it won't blow up if you enter bad data, but some things
like the instruction set are not validated, could produce
a pile of rubbish and terminate if one little thing is wrong.

If you want to use the Benchmark feature, place the warriors
you wish to test against in the current directory (if using
the runonrd batch they'll be copied over), or specify a
filemask for the benchmark warriors under Parameters,
c:\wilkies\*.red for example. The wildcard is necessary.
Benchmark results are for information only, they are only
for judging how effective the results are.

For directed evolution influenced by external code, birth
testing must be on (Parameters then Start/eval options).
The test warrior file new members must battle can be
specified, test.war by default. If the file doesn't exist
it is created with a single jmp 0 instruction. Don't be
surprised if enabling kills most of the warriors, for
best results let the system evolve naturally before
enabling (the test delay variable), or start with tested
code by turning on start testing. Either way it takes
a while for strong code to build up.

Avoid pressing keys while evolving or benchmarking, it's
a pmars thing. If you do, backspace it out then press c
then enter and things should continue. When evolving you
can press control-c to get back to the menu even when pmars
seems locked up. It's not locked, just in debug mode but you
can't see the prompt. If all the warriors die out, crashing
pmars won't help since it never runs. In that case press
any key to return to the menu. To start over, Parameters
then Start/eval options then Begin new population.

As with running any dos-based evolver make sure your dos is up
to par.. type MEM at a prompt and see what the largest exe size
is, mine says 597K. If too much under that you may have problems..
CONFIG.SYS should begin something like this to load dos high...

  device=c:\windows\himem.sys
  device=c:\windows\emm386.exe ram
  dos=high,umb
  ...

Also change other device= lines to devicehigh= to load the
drivers high and free up even more dos memory. Then again,
I just made all mine device= leaving only 545K free and
encountered no errors.

Have fun!

. . .

It's been over a year since I've messed with the code, then the
"itty-bitty" #2 redcode contest results came and lo and behold an
evolved warrior by Dave Hillis placed first, another evolved by
Ken Espiritu placed second. About time! More information about the
contest is on Ilmari's page: http://www.sci.fi/~iltzu/corewar/imt2/
Although I missed it, I am finding the little guys particularly
suited for evolution. So far I've made no changes to RedMaker's
main code but added a few convenience features/fixes to make the
program easier to use and not say that coresize 80 is "bad data".

Changes for 2.6/2.7... Nov 1999

In the validate data subroutine, reduced the minimum core size
to 40 (for making itty bitty warriors). Added "other" menu options
for changing pmars, pmarsv and mtpmars (benching) command lines,
so that I can specify "-l 4 -d 4" options to prevent halting
while making the little guys. Otherwise pmars tends to randomly
bomb with coresizes below 100. Modified benchmark format slightly
to allow up to 22 battle results on screen before scrolling.

Expanded instruction arrays to allow specifying multiple
instances of same instruction or modifier - for increasing
the odds of particular combinations. Added access to the
pmarsv "-v xyz" sub-parm for text and graphics modes.
Added Y/N to create initial population, N goes to main
screen. Of course nothing can evolve if no warriors but
can adjust parameters and start again. Fixed restart bug
in compiled version when interrupting initial creation.

To evolve for 80, set coresize to 80, processes to 80, cycles
to 800 and set the command lines to "pmars/pmarsv -b -l 4 -d 4".
To slow down the run display use "-v 704" for the text parm.
These are on "other options" from the "parameters" screen.
For test warriors I used the contest winners that were posted
to rec.games.corewars - IMT #2 Results (Nov. 2, 1999).

----------------

Changes for 2.8...

Added an option (on by default) that ensures that equal code
receives equal scores when battling by running two fixed battles
with the positions reversed, thus avoiding undeserved promotion.
Now other forms which are less sensitive to starting position
have a chance, like replicators. When enabled the battles are
doubled so it's slower, to turn off and use the original random
battles go to parms then other options, R) Double battle fixed.

----------------

Changes for 2.81...

Added option to replicate immediately to vacated positions
caused by winning a battle, rather than waiting for another
turn then maybe getting a chance to replicate.

2.82 - early version of tracking and battle-surrounding
but without the crossover option. My ref, not released. 

----------------

Changes for 2.83... Aug 30 2000

New option that writes extra information in comments after the
ends of warriors, on the start/eval screen (well.. almost fits
and that screen is relatively empty...) If "Some" is selected,
then tracks origin, generation number and iteration. If "All"
is selected also writes parent info, tracks and writes number
of battles survived and average score. The all option causes a
rewrite (via temp file, delete, rename) of every warrior battled
and greatly increases disk access while evolving, use a ram disk.

Now can visually battle neighbors - use the number keypad to
indicate direction (num lock on if not), [1] battles the warrior
against its SW neighbor, [6] against its east neighbor, etc.
[5] battles the warrior against itself. Random opponent start
position unless the pmarsv comline is appropriately altered.

Implemented a crossover option, off by default. If a matching
neighbor is detected, then evolves code pulled from both warriors.
The mix courseness variable (under "other options") determines
how big the chunks are relative to the warrior size, must be
above 0 and typically under 1. Bigtime experimental!

Now prints the soup iteration count on the main menu.

----------------

Changes for 2.84... March 25 2001

Added new soup views - display by species, battles survived
or warrior length, color by species or actual data displayed.
Now I can quickly hunt down survivors for more testing, cool.

New red-mix mode - mix with Any warrior regardless of species.
Added code to manipulate the origin string if species mix (if
extra info in comments selected, under Start/Eval options) -
first it adds "mixed with" and the new origin string, if further
mixing occurs relabels to "mixed Xy species", "Xy"=species name.
(very imperfect! but better than no tracking at all)

Minor changes.. When mixing the initial code source is now the
warrior selected for evolution, was a random pick between selected
and mate. Generation count is now based only on selected warrior,
was selected or mate whichever was higher.

Dropped the info screen, more room for code.

Changed the default parms to produce coresize 800 warriors.
Note.. still using "pmars -b" for both benching and evolving,
for slightly better results in 800 use "pmars -b -l 20 -d 20".
Left as-is to eliminate mysterious errors if forgotten when
setting up for larger/8000-size warriors. New defaults also
weight instructions and other changes in attempt to create
stronger warriors "out-of-the-box". Whether successful or
not remains to be seen.. really strong warriors usually
don't appear until 100K+ iterations, unless/if luck occurs.
Due to the inherently random nature of the process, exact
results are not repeatable.

On start/eval parms screen, added setting for Soup directory,
set this to a ram disk (like F:\soup if F: is your RD) to avoid
having to copy everything to the ram disk. Added an auto-start
option with the hopes of being able to run as a screensaver,
unfortunately being 16 bit code, Windows won't oblige me :(
need to write a scr stub to launch it. Great though for
auto-starting evolution after taking a long time to create
a tested population, rather than waiting 'till morning.

----------------

Changes for 2.85... March 29 2001

Added "Adjust local refs" option (on other options screen),
"Off" for no adjustments, "On" to adjust local numbers after
line insert/delete operations, "Sometimes" for random pick
between no adjustment, forward only, reverse only or both.
Numbers are adjusted only if they fall within the warrior
and the line they (possibly) refered to was moved. Doesn't
attempt to determine if the number is really a reference,
but it definitely helps to preserve algorithms, without
adjustment adding/deleting lines usually produces damaged
code but not always, hence the sometimes option.

Coding this was tricky since RedMaker is a file-based
evolver.. no memory copy to simply go through.. rather
when an insert or delete occurs (and adjustrefs enabled)
it calls a subroutine which closes the partially evolved
file, reopens it for read to go through adjusting affected
numbers writing results to a temp ??.r file, renames it
back to .red and opens in append mode before returning
to the calling code which keeps on writing unaware that
its previous results have been edited. The insertion
point is noted so that backwards refs can be altered
as they are written without even more file juggling.

When starting a new population, only files that should
be there are removed from the soup directory, rather than
all files. Specifically *.red, *.r, re*.def and re*.dat.
If any other files are present they won't be removed and
the restart will fail. Delete any extra files manually.

Minor fixes/cleanup here and there, corrected a jump out
of a subroutine (not that it mattered, only for user error:)
rigged the other options screen to cram in one more parm, etc.

----------------

2.85a April 6 2001...

Default parm changes - fix local refs option "off" and
double fixed battles "on". In limited trials the fix refs
option tended to stifle production of new strategies in the
early stages, seems to work better if enabled after an
interesting form has evolved. Results seem to be somewhat
better when using the double fixed battle method which
ensures that equal code receives equal scores.
Your results may vary so experiment.

----------------

2.85b April 6 2001... got a bit more time...

More default parm changes to max survival, survival score
adjust rate, start density, local number chance and deviation
and probably other parms. Parms changed to values suggested
by recent experiments (mostly failures:) but I still don't
know what I'm doing, never take anything I default to as
optimum.. the game is too random and my computer is too
slow to perform enough full runs to make my results more
than just somewhat statistically significant.

----------------

2.9 September 20 2001... (not released)

Taking a hint from the other evolver programs, RedMaker now can
optionally copy warriors that perform well to a save directory
and periodically reintroduce them into the soup. To use this
feature, the 'Extra info in comments' setting (Parameters,
Start/Eval options) must be set to 'all', and 'Save/Re-intro'
must be set to 'On'. 'Save threshold' controls how many battles
a warrior must survive before saving (default 10), 'Re-intro
chance' controls the frequency of reintroduction (default .005
for on average every 200 iterations). 'Save directory' defaults
to 'warsave', change to save to a ramdisk (i.e. F:\warsave if
ramdisk is F) or other directory. 'Max saved warriors' limits
the number of warriors in the save directory (default 50),
checks and randomly deletes excess every 1000 iterations.
Reintroduced warriors occupy their previous positions and
accumulate further battle points. The code to test the
battles statistic occurs before the loser is deleted, so
reintroduced warriors will always accumulate at least one
battle point, and warriors that reach the threshold are
saved even if they lose the last battle.

RedMaker's evolution mode can now be stopped by deleting a
DEL2STOP file created in the current directory. A batch file
makes this a double-click operation, save as StopEvol.bat
or similar...

  @echo off
  if exist del2stop del del2stop

Added a "break off" command to help avoid occasional problems
when halting evolution via ctrl-c, made worse by the extra
basic code and commands in the evolution loop. Ctrl-c halting
should work ok now but break processing can be a fragile thing,
the DEL2STOP method is much cleaner.

Redmaker now has more core views - by score/10, by generation
and by generation/100. All numbers displayed mod 100 to fit in
two digits. Sometimes the numbers get lost in the color, so
the color selector now has an 'off'. 'Extra info in comments'
must be set to 'all' for the new core views to function.

The iteration variable is now a double-int to prevent "hanging".

----------------

Version 2.91 December 27 2004...
 
Changed the test for a previous soup so that it looks for the
warcode\redmaker.dat file instead of warcode\nul, which is not
supported by alternative operating systems.

Changed the code that checks for test.war so that it is always
created if it doesn't exist, whether it is needed or not. This
is less bug-prone than trying to detect which options actually
need it. Removed redundant checks.

Added 'somethingthere' variable and used to prevent looking
for savedir warriors unless at least one warrior has been saved
in the current session. Avoids a 'file not found' error message
during initial evolution before anything gets saved. There may
still be logic errors lurking, it's spagetti after all.

Note... beware of the re-intro option when restarting, warriors
from previous soups will likely "take over" the current soup
before anything evolves that is strong enough to resist.

Altered the default variables to reduce the line-change and
perfect-copy rates, still you'll probably need to mess with
the parms to generate strong code (depending on your luck).

Added a GPL (c) message to startup, removed old COPYING file.

Running Redmaker under Linux...

The Linux environment I'm using is Knoppix 3.6 Linux installed
to the hard-drive (single-user mode just like running from CD),
running DosEmu version 1.2.1.0, running FreeDOS kernel 1.1.35
with the FreeCom 0.82 command processor. RedMaker expects a
msdos-compatible shell that understands dir /-p /b deltree /y
and other normal dos commands, it will not work properly under
DosEmu's built-in command shell as configured by FreeDos beta 8.
Download FreeDos beta 9 from the DosEmu page and install it
manually, you'll need to make a link to the new directory and
put where the existing freedos link is (/var/lib/dosemu here),
then edit dosemu.conf to use the new link name. Hang on to
beta 8's autoexec.bat, it sets up a more convenient drive setup,
copy the relevent lines into beta 9's autoexec.bat... for some
reason I could not make the C: drive anything but read-only which
won't do very long with TEMP assigned to it.. beta 8 sets up D:
as the Linux home dir (I appended /MYDOS to limit what it sees)
and E: as a writeable temp dir, same autoexec.bat commands
worked fine. The beta 9 dosemu/freedos tar.gz I got didn't
include a dosemu directory (contains all the stuff that makes
the native Linux file system look like "dos"), the dosemu dir
from beta 8 works fine or copy the utilities from the dosemu
package to your freedos "C:" image (haven't tried).

----------------

Batch files for saving and loading the ram disk...

------ cut SAVERD.BAT -----------
:: deletes C:\RamDisk then
:: saves ram disk to C:\RamDisk
:: set ram_disk=letter of your ram disk
@echo off
set ram_disk=F
if not exist C:\RamDisk\nul md C:\RamDisk
deltree /y C:\RamDisk\*.*
xcopy %ram_disk%:\*.* C:\RamDisk /e
cls
-------- stop cutting -----------

------ cut LOADRD.BAT -----------
:: loads ram disk from C:\RamDisk
:: set ram_disk=letter of your ram disk 
:: does NOT delete, for use when RD is empty
@echo off
set ram_disk=F
xcopy C:\RamDisk %ram_disk%:\ /e
cls
-------- stop cutting -----------

Edit these before use to specify your ram disk, F is mine.
Remember to run SAVERD.BAT before rebooting or shutting down.
It's easy to automate restoring the RD, just put LOADRD.BAT
or a shortcut to it in windows\start menu\programs\startup,
but I haven't figured out how to automatically run the save.
Make sure that C:\RamDisk isn't used for anything else since
it is deleted before saving new contents. Alter all instances
of the C:\RamDisk string to save to another directory.

SAVERD.BAT is not strictly XP-compatible but should work
once a compatible ramdrive is installed. Linux/DosEmu/FreeDos
shouldn't need a ramdrive, the Linux file system acts like a
ramdrive already and saves up writes to deposit efficiently.

--------------
Terry Newton
wtnewton@infionline.net
http://www.infionline.net/~wtnewton/
