Evolving core warriors usually involves starting with a bunch of random redcode then running a process which battles them against each other, removing the low scoring ones and imperfectly copying the winners to unoccupied space. Several systems are available if you look hard enough, mostly for Unix but I managed to get a few running.
Related links and papers...
Listings and benchmarks of evolved warriors...
If anyone is wondering why someone might evolve warriors, there isn't a simple answer. If you aren't naturally attracted to artificial code-life etc this stuff probably won't make much sense. Why do people run Conway's Life? look at Mandelbrot plots? study Tierra? carefully tend to an aquarium full of evolving core warriors? Who knows, just stuff I do.
I probably need to start a section for dos batch files... these aren't particular to any one evolver...
TESTALL.BAT - benchmarks all warriors in the current directory against c:\warbench\*.red and produces a report in warbench.txt containing sorted scores and a listing and performance chart for each warrior tested. Requires qbasic and pmars, edit batch to specify command line and bench directory, set to 800 size, 100 rounds fixed.
BATTLE.BAT - runs a hill on all redcode in current directory. Requires pmars and scorelog.bat, edit to specify pmars parameters, set to size 800 100 rounds fixed.
SCORELOG.BAT - processes a pmars-generated log file and produces a sorted list of scores. Requires qbasic.
SAVERD.BAT and LOADRD.BAT - batch files for saving and loading ram disk contents.
Many other batches are scattered about this page. All are for msdos 6 or greater, tested only with dos7/win95 except for some old ones from the 3.1 days. Most require QBASIC.EXE, which was shipped with older doses but nowadays usually isn't installed by default. Sometimes it's on the Windows CD in other/oldmsdos, it's also on Microsoft's web site... somewhere. Try: ftp://ftp.microsoft.com/Softlib/mslfiles/OLDDOS.EXE - at least that's where it was.
The first evolved warriors I "brewed" were produced using the GA_WAR program by Jason Boer. No modifications were made to the software, just compiled it with Turbo C++ (for Dos) and it worked the first time.
These batch tools were also used...
MARS.BAT - a shell for pMars with options
for battling and scoring groups of warriors.
TESTRC.BAT - a batch for battling and scoring
group of warriors against one or more groups.
SCORELOG.BAT - processes raw scores to produce
ordered warrior score percentages.
INSPECTS.BAT - inspects raw scores to see
how a particular warrior performed.
The latter two are command-line utilities that duplicate the scoring and inspect functions of MARS.BAT, but faster when analysing logs from previous battles. All require QBasic. Some call LIST for listing results. If you use these, you'll probably have to customize them to your system and needs, in particular edit TESTRC.BAT to set the correct pMars directory.
If you tuned in earlier you saw preliminary results but I have better data now, so time to prune the complexity of this page once again to make room for new results. To summarize, I used Jason's GA_WAR program to create a population of 40 warriors which I let evolve for a total of 3968 generations, taking samples at various points and also making changes to the config file as I went. In total, I ended up with twelve directories, a main and valhalla directory with 40 warriors apiece sampled at six different generations.
What's interesting about Jason's evolution program is it's a closed system - external code is never used to evaluate anything. It all begins with randomly chosen instructions which pass only the minimum of fitness, then they are mutated and crossed amongst themselves. As they battle each other the evolution system copies definite winners over definite losers while slowly introducing random mutations into the mix. The good mutations win more, so pass their code on to the now lesser members of the population. Highly simplified but close. After thousands of iterations a few can hold their own against some human-written warriors, but only incidently. Except for messing with the config file and picking out winners, these evolved warriors have no benefit of human encounter, no opportunity to better themselves in response to a new threat. They're at the bomber (and crasher:) stage of evolution, it'll be a long time before a paper pops out of the pit. A vampire maybe?
One thing for certain, consistant corewars is not - a warrior that does good against one test set does not necessarily do well against another. And unless a large number of rounds are played per battle the results are not accurate. That includes the results so far which were scored at 20 rounds per. Not enough really, a warrior can get lucky a few times and end up with an inflated score. The problem is numbers and processing time - evolving the ha_ series produced 480 warriors to have to sift through, most of which are not very good.
What I did was use a master job batch to call TESTRC many, many times to battle everything against three test sets: the first set of 7 older warriors (mice, bravo, etc), a group of 28 warriors from my corewar page, and a set of 12 benchmark warriors picked out by someone, can't remember who. Good set though, they slam. I ran separate tests against all three sets at 25 rounds per battle, this took a couple of days. Next I picked out everything that scored 45% or better against the easy 7, 33%+ against the diverse 28, and 20%+ against the difficult 12. This gave me 23 possibilities after weeding out the duplicates (made a neat batch for doing this, of course). Currently I'm battling them all at 100 rounds against all of the benchmark warriors at once, 44 warriors in all which I hope will give me a reasonable cross section. Once I get the best-of-the-best from the ha_ generations, it'll be time for another full-play battle along with a couple of samples from earlier runs (especially that ez_16) and a couple of evolved warriors from others to see where we all stand.
For this test I selected the best 8 of the ha_ series, 2 of Jason's evolved warriors (ga_24 and zz_972), 2 evolved warriors from previous runs (ez_16 and cz_3), 2 evolved warriors produced by "karl", the 12 really good benchmark warriors and 6 more older ones thrown in for good measure, 32 in all. In this test, every member plays every other member twice, once in each position, and itself once. The battles were run 50 rounds per match, each warrior battles each warrior a total of 100 times.
073.1 Porch Swing by Randy Graham 073.0 Marcia Trionfale 1.3 by Beppe Bezzi 071.3 nobody special by Mike Nonemacher 070.7 TimeScape (1.0) by J. Pohjalainen 067.7 Rave by Stefan Strack 067.7 Paperone by Beppe Bezzi 062.7 Iron Gate by Wayne Sheppard 061.2 Thermite 1.0 by Robert Macrae 058.1 Cannonade by P.Kline, Paul Kline, pk6811s@acad.drake.edu 056.4 Blue Funk 3 by Steven Morrell 049.6 Ecstacy by : Stefan Roettger / Sandstrasse 3 / W-8525 Uttenreuth / Germany 047.9 MICE by Chip Wendell 047.6 Torch by P.Kline 045.2 Fire Storm v1.1 by W. Mintardjo 042.8 zz_972.red by Anonymous 042.1 ha_5.red by Anonymous 040.9 ha_36v.red by Anonymous 040.3 Comper-2a by Andy Pierce (ajpierce@med.unc.edu) 040.1 Virus by Jay Han 039.7 Tornado by Beppe Bezzi 038.5 ha_37.red by Anonymous 037.6 ha_18.red by Anonymous 033.5 GA_24.red by Anonymous 029.2 W0078V00 by RC94 Evolver v2 029.0 ez_16.red by Anonymous 028.8 ha_31a.red by Anonymous 027.8 ha_28c.red by Anonymous 027.8 ha_12c.red by Anonymous 027.7 Bravo by Corey Lynn Nelson 027.0 ha_3c.red by Anonymous 023.5 G008W041 by RC94 Evolover 023.1 cz_3.red by Anonymous
Performance of some using the "Wilkies benchmark"...
HA_31A pmars -r 100 HA_31A.red HA_31A.red - - - - - - W L T Score time.red : 0 76 24 24 nobody.re: 0 82 18 18 paperone.: 4 77 19 31 marcia13.: 0 84 16 16 bluefunk.: 0 18 82 82 cannon.re: 54 33 13 175 tornado.r: 25 14 61 136 fstorm.re: 71 26 3 216 rave.red : 14 86 0 42 irongate.: 17 78 5 56 pswing.re: 2 67 31 37 thermite.: 6 53 41 59 - - - - - - - - - - - - - - - Total wins = 193 Total losses = 694 Total ties = 313 Overall score is 74.33334 HA_3C pmars -r 100 HA_3C.red HA_3C.red - - - - - - W L T Score time.red : 0 96 4 4 nobody.re: 1 98 1 4 paperone.: 0 86 14 14 marcia13.: 0 100 0 0 bluefunk.: 0 15 85 85 cannon.re: 39 60 1 118 tornado.r: 29 18 53 140 fstorm.re: 66 33 1 199 rave.red : 12 88 0 36 irongate.: 43 54 3 132 pswing.re: 2 92 6 12 thermite.: 1 64 35 38 - - - - - - - - - - - - - - - Total wins = 193 Total losses = 804 Total ties = 203 Overall score is 65.16666 EZ_16 pmars -r 100 EZ_16.red EZ_16.red - - - - - - W L T Score time.red : 0 99 1 1 nobody.re: 0 99 1 1 paperone.: 5 85 10 25 marcia13.: 0 100 0 0 bluefunk.: 0 15 85 85 cannon.re: 36 63 1 109 tornado.r: 28 18 54 138 fstorm.re: 46 54 0 138 rave.red : 44 56 0 132 irongate.: 47 51 2 143 pswing.re: 5 67 28 43 thermite.: 1 86 13 16 - - - - - - - - - - - - - - - Total wins = 212 Total losses = 793 Total ties = 195 Overall score is 69.25
The Sys 4 evolver is a set of perl scripts written by George Lebl that simulates a two-dimensional array of redcode where the warriors battle their neighbors. It is alife-like in its approach, very interesting to watch...
Here's a dos/win32 version of Sys 4, includes the original code in a tar file. It's GPL. See port notes. To run you'll need a Windows 95 machine, Perl for Win32, and pmars 0.8 for dos. You'll also need QBasic (and maybe other "missing" dos files, get the dos suppliment from MS), and some test warriors like those from the Wilkies Benchmark.
Warriors it made for me...
Benchmarks...
OZEL106 pmars -r 100 OZEL106.red OZEL106.red - - - - - - W L T Score time.red : 1 93 6 9 nobody.re: 0 95 5 5 paperone.: 2 83 15 21 marcia13.: 0 100 0 0 bluefunk.: 0 22 78 78 cannon.re: 14 82 4 46 tornado.r: 23 22 55 124 fstorm.re: 71 26 3 216 rave.red : 34 66 0 102 irongate.: 32 65 3 99 pswing.re: 7 56 37 58 thermite.: 11 50 39 72 - - - - - - - - - - - - - - - Total wins = 195 Total losses = 760 Total ties = 245 Overall score is 69.16666
BMEA014 pmars -r 100 BMEA014.red BMEA014.red - - - - - - W L T Score time.red : 0 91 9 9 nobody.re: 0 98 2 2 paperone.: 3 86 11 20 marcia13.: 0 100 0 0 bluefunk.: 0 23 77 77 cannon.re: 42 33 25 151 tornado.r: 25 37 38 113 fstorm.re: 68 26 6 210 rave.red : 15 85 0 45 irongate.: 47 52 1 142 pswing.re: 7 70 23 44 thermite.: 12 56 32 68 - - - - - - - - - - - - - - - Total wins = 219 Total losses = 757 Total ties = 224 Overall score is 73.41666 DZAR513 pmars -r 100 dzar513.red dzar513.red - - - - - - W L T Score time.red : 0 94 6 6 nobody.re: 1 96 3 6 paperone.: 0 84 16 16 marcia13.: 0 78 22 22 bluefunk.: 0 19 81 81 cannon.re: 21 58 21 84 tornado.r: 23 21 56 125 fstorm.re: 83 17 0 249 rave.red : 23 77 0 69 irongate.: 43 51 6 135 pswing.re: 1 73 26 29 thermite.: 4 56 40 52 - - - - - - - - - - - - - - - Total wins = 199 Total losses = 724 Total ties = 277 Overall score is 72.83334
My implementation makes heavy use of batch files and although it's designed for Windows 95 it's as dos as it gets. As far as the port itself, the modifications are mainly confined to the sys4.pl file. I'm not really a Perl programmer, but I can cut paste and hack until it works... Fortunately it didn't take much, pipes and messages aren't the same (if they even exist...) in the Windows environment so pipes are changed to temp files (that's what they are anyway) and messages, unless I figure out how to do it otherwise, are passed by deleting signal files. Crude but effective. Another irritating aspect of Perl under Dos is a script cannot rerun itself, at least not without keeping the old copy in memory. Something about extreme string manipulation for hours makes it run out of memory so if it doesn't periodically restart it'll be waiting with an 'out of memory' message for the operator. To solve this problem, the code was modified to write a flag file and terminate so that a batch file can detect the flag and rerun the script. So that it remains self-contained the script is contained within the batch itself.
The front end batch handles the starting and stoping of tasks and allows the evolved warriors to be charted and examined in various ways. The tasks involved are initialization, evolution and testing. Evolution shouldn't run while testing, and neither can do anything until initialized, the menu options change to indicate what's available to do. For looking at the warriors, the array can be mapped by name, size, score or generation. An inspect option overlays a cursor for listing, testing, editing, saving and deleting individual warriors. Finally got color! All this coolness comes at a price though, being "just" a batch file it's subject to errors should your installation differ much from mine, to get it running not only to you need Perl for Win32, but qbasic, find, mode, debug and other standard dos commands. Standard Windows 95 installations leave out some of the files but they are on the Windows installation CD and downloadable from Microsoft.
File updated March 6, 1998 - If today's date is anywhere close consider
it under construction...
Latest hacks: minor... makeword.bas now included in slightly cleaned up
form, handy thing to do between runs. Added back an ansi home option for
me and anyone who still uses ansi, edit batch to enable.
August 15, 2000 - Link to SYS4CONV.BAT - an msdos batch file that converts other warriors to System 4 format, qbasic and pmars must be on the path. Warrior must start execution on the first redcode line, hardcoded for length 25 - edit batch and change set maxlen=25 for other lengths.
Evolutionary Observations...
Scores for evolved warriors made by either Sys 4 or Ga_war tend to top out at less than 80 in my experiments, decent man-made warriors usually score well over 100. My warriors might get 60 on a good day. There are reasons why better warriors don't appear, first and foremost is the evolution array usually fills up with brain-dead djn thingies (the worst are like ez_16.red, a single DJN instruction) and a warrior that does well against such stupidity usually will not do well when battled against real code. The inverse is also true, a warrior that does well in benchmarks usually gets devoured by the djns. Good warriors can appear only to be swallowed up by simpler forms. Such is life! They must get detected and saved before they go away. One trick that seems to work is to delete all of the warriors except for a few high scorers. Another trick might be to introduce "predator" code into the warrior array, Sys 4 saves family names, making it easy to ignore the damaged predator code.
Evolved warriors are an alife thing to me, entities which arise out of random change and natural selection. Comparing them to warriors written by programmers is an indication of strength but there should be no false expectations. They are their own kind and play by their rules. To further the alife aspect there should be communication of warrior samples between evolution pools (all 3:). In a way there is... the samples on this page, terrible as they are, can be used to give evolution a kick-start and further their own designs. If someone (or something) emailed me an evolved warrior it's no biggie to put it in the current brew.
Sys4 brewing notes... here's a frustrating thing... evolving a mix for a long time often produces no better results than evolving a short time. Evolution is a luck kind of thing, and usually there is not enough luck to go around for a core creature family to change from one code form to another and survive, the best it can do is improve the existing form. Poor forms still make great stupid code killers so they quickly take over, but are what they are. The trick is in the genesis, workable forms must exist at the get-go. Granted, the evolution can take the most wretched code and get it scoring in the 45 (15%) range but a good mix should score that after only a few generations. If not, start over. Real life evolution takes millions of years and members. Given the limited confines and relatively no pressure environment of corewarrior evolvers, it's not surprising that they often don't improve much. There is no reason for them to.
Ways to exert more pressure...
Randomly benchmark the warriors and delete the bad performers.
Mobility - in Sys4 warriors are stuck where they are, move the files around.
Directly insert good warriors, but I keep shying away from the idea.
Keep good evolvees from many runs then put them all in the same soup.
Generate new random warriors in large unoccupied spaces, one might get
lucky.
Even with much effort, sometimes they just don't grow into what I would consider acceptable. I recently added a 'run' option so that I can cursor to a warrior and see what it does when it runs by itself in the core. Facinating... and sometimes depressing. In the early going, the only pressure is to make code that just runs but doesn't particularly do anything, but if better at doing nothing than its neighbors it can take over leaving the brewer with a bunch of nothings. If ran long enough they eventually turn into something but usually it isn't good. Tweeking the minscore and maxscore variables help but got to be careful, warriors that perform halfway decent often score 100 against themselves, scores of 300 usually mean the warrior was surrounded by nonfunctionals. You can't go by the scores when picking out good code, but a cluster of 20s might indicate a species that wins or loses against itself, 5 5 0 instead of 0 0 10.
This is an experimental evolver I put together using QBasic to serve as an idea testbed. I'm too impatient to learn a new language and modify existing code, so I decided to start from scratch in a less stressful language. It came together a lot faster than I expected, even works...
The look of the display is similar to the colorized Sys4 map script, updates in real time. In the original Redmaker 1, all variables are set by editing the basic program. Redmaker 2 has an interface for browsing the warrior array and provides access to most of the parameters without editing. For MsDos (or dos under Windows), requires the pmars software. The .bas files require qbasic.exe to run interpreted, in the olddos.exe package from Microsoft.
Here are some RedMaker warriors...
September 2000 - lately the SourceForge Corewar Tiny Redcode hill has been a battleground for evolved warriors, this hill uses a coresize of 800, 800 max processes and 8000 cycles. Some of my efforts.
RedMaker notes...
The evolution engines of the original RedMaker 1 and version 2 are practically identical, the main difference is version 1 has no user interface, edit the source code to change parameters. I got tired of having to browse and test the output manually, so added a user interface so I could cursor to a warrior and run in pmarsv, list or benchmark. Parameter screens allow access to most of the variables, the settings can be saved to a data file to make default. The new version is supplied as both a .bas and a compiled .exe file, there isn't hardly any speed difference but qbasic.exe is getting rare these days. The .exe version needs only dos and the pmars software on the path or in the same directory.
I've noticed a few things that majorly impact evolution speed and effectiveness. The chosen instruction set makes a lot of difference! If the full corewar instruction set is used, the warriors can evolve to be a bit stronger but it takes much longer. Selecting fewer, more useful instructions yields much faster results. The new version allows no modifiers to be specified to produce simpler '88 style instructions. Core size makes a big difference, things happen faster at 800 rather than the traditional 8000 location core. The evolution rate parameters, particularly line change rate, make a noticeable difference. Line change rates of .05 or less eventually yield stronger code however the higher rates make things happen quicker and produce more differentiation among members of the same species. Directed evolution can also be specified, this requires that all new members beat a specified warrior, defaults to jmp 0 but that has a tendency to produce many boring single instruction core clears (that often score quite well but not quite what I'm looking for). If the junk gets too much, remove the DJN instruction.
Link to RDRED.BAT, a batch I use to run Redmaker on a ram disk and keep the warriors compressed in a zip file. Requires PkZip and PkUnzip to operate. Before using, edit the batch to indicate the letters for the hard drive and the ram drive. As written runs the uncompiled version, change the line 'qbasic /run redmaker' to just 'redmaker' to use with the compiled version. (Aug 15 2000 - another ramdisk runner for Redmaker, RED.BAT)
RedMaker 2.5 was posted Aug.15, 1998. Program archive last changed Nov. 5, 1999 - version 2.7 - modified to allow using small cores, provided access to the pmars/pmarsv command line parms for tweeking, like using "-b -l 4 -d 4" for making "itty bitty" warriors for coresize 80. Other minor additions and bug fixes. No changes to the main routines.
August 14, 2000 - Link to RMCONV.BAT, a batch I made that converts general redcode into a form that Redmaker can evolve. Redmaker warriors must begin execution on the first code line, if the warrior uses ORG or END x then it cannot be converted as-is - add a jump to the entry point to make partially equivalent. Note - RMCONV.BAT requires both qbasic.exe and pmars.exe in a path directory. Takes input and output files as command line parms, to convert say warrior.red to aa.red, drop to a dos prompt in the directory and enter "rmconv warrior.red aa.red". Without the quotes of course. Input and output file can be the same to overwrite the original, as in "rmconv my.red my.red". August 15 (b) version - 4 character name can be specified on command line, as in "rmconv my.red bc.red BcBc".
August 15, 2000 - here's what I've been using to sort through RedMaker's output... RMBENCH.BAS. Requires Qbasic [Sept. 2 - no longer requires scorelog.bat, copied into the program to avoid memory problems]. Benchmark paths and pmars command lines are hard-coded, edit (or configure your bench directories to match) before using. RMCONV.BAT updated to ignore assert line, made same mods to SYS4CONV.BAT. To make it easy to convert an entire hill to redmaker I made RMALL.BAT, converts all warriors in the current directory (up to 20 or so) to redmaker format, leaves in rmconv directory with a log of what's what. Rmconv.bat must be on the path or in the current directory.
August 17, 2000 - uploaded Redmaker 2.8 - fairly minor change to add an option for battling twice with the warrior positions reversed. Thanks to Martin Ankerl for suggesting this little trick that helps to produce more interesting forms. Finally I was able to evolve replicators, a few appeared in one of the species after about 14000 iterations with the survival score at 95 (which also allows lots of dud code to exist if not challenged). After raising the survival score to get rid of the duds the replicators disappeared too... which was not unexpected since they generally tie against themselves.
August 20, 2000 - replaced with Redmaker 2.81 - added an option that replicates the selected warrior immediately if it won and the warrior it was battling was removed. Before it had to first clear space, wait another turn and then possibly get a chance to replicate - if a lesser form doesn't crowd it out and force it to do battle again.. now, if the "Replace removed loser" option is selected it replaces the beaten warrior with an evolved copy of itself, thus rewarding stronger performance with extra replication. Sounds good in theory... seems to help but about everything about this stuff is a "seems". Results of any one run do not necessarily reflect on the quality of the chosen parameters.. sometimes it does.
August 31, 2000 - New features for version 2.83...
Optionally tracks code origin and generation number in comments appended to warriors, and if "all" is selected also notes parent(s), number of battles survived and average score but that takes more disk access. Under parameters, start/eval. The origin comment stays with all offspring. To help track re-evolution experiments, updated RMCONV.BAT so that it extracts and records the original warrior name in converted warriors.
Added an experimental crossover option - Normally, Redmaker chooses a random warrior, then chooses another surrounding cell. If the surrounding cell is occupied it battles the two warriors and removes the one that loses or scores below a certain level. If the chosen surrounding cell is not occupied, the focus warrior is evolved to create a new warrior to fill the empty cell. If crossover is enabled, then before replicating another surrounding cell is chosen, if it contains a warrior of the same species, then code from both warriors are used to make the offspring otherwise replicates from the one parent. A courseness variable (under parameters, other) determines how fine the blend is, larger numbers result in larger intact chunks. The warrior to pull from first is determined randomly. Well... theoretically it should work, we'll see...
Finally, a fun new feature - can now visually battle the selected warrior against any of its neighbors to see what becomes of the code under combat conditions. Use the numeric keypad to select the warrior to battle against, for example [4] for west, [3] for southeast, etc. The [5] key battles against self.
September 2, 2000 - apparently the crossover option doesn't hurt... at least the strongest of an evolving population increased in strength when I enabled mixing. Notes about evolving size-800 warriors have been moved to tinyevol.html.
March 25, 2001 - new RedMaker version 2.84, mostly interface changes but added a new "RedMix" mode that bypasses the species check, perfect for mad experiments like evolving hill warriors into an existing soup. Made a vain attempt to account for multiple origins on the origin comment line. Minor changes like always taking evolved code from the selected warrior first regardless of mixing (was random pick), the selected warrior is used to determine generation count since usually it's the first lines that matter the most. Major interface change, now it can display warriors not only by species but also by length or battles survived, gets the color back when the soup becomes all the same species and also useful for visualising sub-species evolution and hunting down successful code. Useful interface change, now the soup directory can be specified, set to a ram disk to avoid the hassle of having to copy program and all to ram disk, just use saverd and loadrd batch files to save whatever is on the ram disk between boots. New default parameters for 800-coresize and weighted instructions.
March 29, 2001 - new RedMaker version 2.85 - finally coded it, now there's a "fix local refs" option to sometimes or always adjust numbers that refer to positions changed by insertion and deletion operations. This tends to preserve algorithms and avoid breaking the evolved warrior.. although sometimes it is beneficial to break it in the hopes of creating a new algorithm so I think I prefer the sometimes option, evolution will sort it out.
April 6/7, 2001 - 2.85a - default parm changes: adjust local refs off, double fixed battles on. The adjust local refs option helps to optimise an already interesting form, however when starting out it tends to limit the production of new strategies in unoptimised warriors. 2.85b - changed several other default parms, worked a bit on source code formatting.
December 27, 2004 - new RedMaker version 2.91 - This version was edited and compiled while running under Linux, using DosEmu running FreeDos, and it feels like MsDos 6 in a window. Cool! The same fixes that make it compatible with FreeDos also make it run well under XP (SP2) using SDL_pMARS. Now includes automatic save and restore functions, enable under Start/Eval Options (default is disabled). Saves are triggered when a warrior lasts a specified number of battles, and reintroduced according to a chance variable by default .005 or on average once every 200 iterations (can be 0 to disable reintroduction). The maximum number of saved warriors is adjustable (default 50) and you can change the save directory (warsave). Now that I can evolve while running Linux using good old QBasic it might take a bit more convincing to learn the "standard" languages... like C. Emulating MsDos under Linux takes a toll but it's not that slow, I'm getting about 10 iterations per second under Linux and the old pmars08 binary verses about 20 iterations per second using XP and the SDL binary, hard to say how much is because of the OS and how much is from using a faster version of pmars.
YACE stands for "Yet Another Corewar Evolver", it's a Ga_War-style evolver from Martin Ankerl, publically released in August of 2000.
Yace 0.01
Local copy in yace01.zip
This evolver is much like Ga_War - no user interface except that of editing a config file, no graphic display of the members, no support for separating and tracking multiple species, just an evolving soup of warriors. YACE supports Ga_War-style n-dimensional battling plus two different 1-dimensional topologies. One of the coolest things about YACE is it uses an internal redcode simulator, Exhaust, rather than depending on pmars, making it fast and unobtrusive. Exhaust is slightly slower than pmars on long battle runs but for short runs, typically 10 battles, and particularly when evolving 800 size warriors, what speed difference there is is more than made up for by not having to load pmars for every battle.
A 32-bit C compiler appropriate to the OS is needed to produce an executable, I used the GNU gcc tools that came with Bloodshed Dev-C++ to make a console (dos) application for Windows 95, using the supplied makefile and also by adding the program sources to new Dev C++ and VIDE (another shell for gcc/mingw) projects with each environment's default settings. The program uses the files yace.c, sim.c and asm.c, the exhaust.c file is a stand-alone interface for the exhaust redcode simulator and isn't used by the yace program, so does not need to be added to the project file. The simple way to make the program if you have compatible compiler tools installed is go to a prompt and enter "make", on my system this resulted in a 43K executable. Gcc issued warnings about Exaust's sim.c (signed/unsigned comparison on lines 156, 428 and 437) but these can probably be safely ignored. Using the integrated environments, Dev C++ produced a 31K executable and VIDE produced a 23K executable, no warnings were produced by either environment. All three of the executables function properly.
YACE needs to run from a directory besides the root, and the subdirectory "valhalla" must exist under yace's directory. Operating parameters are initiated by a configuration file, edit the file "yace.cfg" to change. Dos/win users must change the path separater to "\\". Each cycle, the file cycle.txt is written with the cycle number on the first line followed by current status. If the cycle number reaches the maximum specified in yace.cfg, or if the cycle.txt file cannot be written, the program terminates. To start a new run, create_new_population (in yace.cfg) must be =1, otherwise =0. If 0, starting_cycle should equal the cycle to start on. For best results the program should be run from a ram disk, like most evolvers it generates lots of disk access.
To make YACE easier to use I created a couple of batch files, RUNYACE.BAT checks for cycle.txt and if it exists updates yace.cfg using an echoed qbasic program then copies yace.exe, yace.cfg and all redcode in current and valhalla to ramdrive and runs yace.exe. When yace.exe terminates it copies cycle.txt and the redcode back to the harddrive. STOPYACE.BAT marks the cycle.txt file read-only to cause yace to stop, if a ramdrive copy is present it marks that one (as written there must be a drive besides the current to check), else marks the cycle.txt in the current directory. This is not exactly "proper", the remaining cycle.txt file refers to the previous generation but no other ill effects noticed. To compensate, RUNYACE bumps the cycle.txt count by 2 when calculating the starting generation. Batch files must be edited to specify the drives before using, as written D: is the hard-disk with the evolver program and F: is the ramdisk.
Aug 23, 2000 - I've only fooled around a bit with a population of 20 warriors, so far by around generation 5000 or so the best score is around 60 against ten 800-size warriors written by Franz. Similar results against the SF tiny hill. I don't think a population this small can take off to any great degree but even so diverse forms were produced, no papers but some look like they want to replicate.
Yace 0.02
Local copy in yace_0-02.zip
This version was released September 3, 2000 and is very different than the previous version. It evolves completely in memory, practically eliminating any need for ramdisk batches - it is running now as I edit this page and there is almost no disk access or any detectable drag on the system, despite close to 100% usage of free cpu time. Installation was trouble-free, I downloaded it, unzipped to a folder I called Yace02 and it creates directories for src, bin, out, save and testset - I went to a command prompt under src and entered "make" - worked perfectly, no warnings, just an executable in the bin directory. The release I got didn't have any instructions... so I ran it. Every 20 cycles (changeable in config file) it saves population warriors to the save directory, also at intervals the population is tested against the warriors in the testset directory and the highest-scoring warrior is placed in the out directory.
Sept. 4, 2000 - The original 0.02 had no exit mechanism, which was a problem for my old win95 box with broken control-break processing when running 32-bit console apps compiled with mingw/gcc. [ends up mingw has worse problems than that, recommend using Cygwin or other to compile] To solve this and similar exit problems the author sent to me a modified YACE that provides a file which will terminate the program when deleted. Perfect, a simple batch that deletes the file can be the "off" switch.
While awaiting termination instructions YACE 0.02 was able to get in a full overnight run. (clever :-) The warriors in the out directory are named according to their score, together with the file date it's easy to see trends... looks like the population steadily grew from the 40's at 8pm to a peak score of 133 around 11pm, then the scores dropped to 60's but came back for a stronger peak of 143 at 2:30am. After dropping slightly then another peak of 130 about 3:30am it's been pretty much down-hill, currently best scores against the testset are in the 60's. YACE's automatic testing and extraction is a very nice feature - no lengthy tests, provides a continuous record of the soup's progress, and nothing is missed. Normally I would have awoke to find weak warriors, oblivious to the much stronger warriors that arose and fell during the night, then have to spend hours evaluating the results... just for one datapoint - this is much better. Now if the population would just get it together again and make another climb...Sept 6 - The 0.02 code crashes intermittently when compiled with the mingw tools, so installed the Cygwin compiler from sources.redhat.com/cygwin/ using the setup.exe on the web page, took hours and about 100 megs of disk space but don't even think about trying to install the pieces manually. After adding cygwin\bin to the path line, "make" worked fine and produced a functional exe.
Things are starting to pick up in the soup...
filename date time score ------------ -------- ------ -------:----=----=----=----=----=----=: ev_11833.red 09-05-00 9:04p 118.33 :*********** : ev_13167.red 09-05-00 9:41p 131.67 :************* : ev_13000.red 09-05-00 10:44p 130.00 :************* : ev_14000.red 09-05-00 11:03p 140.00 :************** : ev_13500.red 09-05-00 11:22p 135.00 :************* : ev_13667.red 09-05-00 11:42p 136.67 :************* : ev_14667.red 09-06-00 12:02a 146.67 :************** : --------------------------------------:----=----=----=----=----=----=:
Chart by chartout.bat - seemed like a thing to do. Scores are against the 6 warriors included with the package, tiny hill scores are presently in the 80's. All of these are papers, 14667 has only 3 functional lines...
spl.x # 17, < 787
mov.i < 3, { 247
djn.f { 249, { 406
dat.b * 208, > 14
Sept. 22, 2000 - text file with a couple of trivial mods for yace 0.02 - my version of an delete-file exit mechanism, and a mod that avoids overwriting existing warriors in the out directory.
Yace 0.03
Local copy in yace_03.zip
This version was released September 18, 2000, and includes an executable so it's ready to run on Windows computers in console mode, like a dos program.
I haven't had time to really give this one a workout yet but initial observations... No problems running it, beforehand I edited the config file to specify \\ as the path separator and dropped the population size, after running for awhile on my slow computer I had a bunch of warriors in the bin\status, bin\koth and bin\soup directories. Koth includes an html file illustrating who beat who, neat. The warriors aren't that strong yet but the run is just getting started.
Yace 0.04
Released October 6, 2000 on Martin Ankerl's web site with a minor archive update on October 9. Compiles fine using Cygwin "make", produces a 65K exe file on my machine. For Windows be sure to edit yace.cfg and change the path separator to "\\". So far it works ok in testing, after about 3 hours on my 133mhz the best status warrior was scoring about 110 against the tiny hill (population size = 50 for testing, will probably have to increase to improve scores).
Added to yacebats.txt...
CHARTSTA.BAT - a modification of chartout.bat
for charting the performance of warriors in the status directory.
Yace 1.0
Dec. 16, 2000 - a new release of Yace has been posted to:
http://www.fhs-hagenberg.ac.at/students/se/se00001/
3/16/06 - local copy in yace_1_0.zip
This one comes with a pre-compiled Win32 exe and is similar to the 0.04 version. I tried it out with a population of 100 and it got up to a "sourceforge" score of around 110 after an overnight run. Chartsta.bat (for Win95) works fine for tracking the results over time.
The new benchmark function doesn't rate my system very well...
------------------------------------------------------------- Fights per second (the higher the better): 120.67 Tolerance (should be lower than 2 percent): 3.49% ------------------------------------------------------------- 0.09 times faster than AMD Duron650, PC133, Win2k.
I have a 133mhz AMD 586 with Windows 95 - I suppose one day I really should upgrade...
After a few more days (a few hours on good systems:) the soup is thick with papers scoring around 125 on various benchmarks. To help tally the results I made "BENCHKOT.BAT" (in the yacebats.txt file) to take a snapshot of the "koth" directory and produce a file containing benchmark charts and listings of the warriors. I had to edit some of the test warriors to get their names reasonably correct, some were missing the newline after the ">" in the email address, in one case resulting in an "unknown" warrior in the bench report from my batch. Other files were in unix format which I fixed with "qbasic /edit" for compatibility with notepad, but the evolver and most other programs don't care. These are minor batch-detected "features", the evolver itself has been totally stable, both the included exe and one compiled with Cygwin, benches ~100 fps.
Things were picking up, then the population went down...
13400000.red 12-19-00 11:16p 134 :************* : 13200000.red 12-20-00 12:07a 132 :************* : 13020000.red 12-20-00 12:50a 130 :************* : 12925000.red 12-20-00 1:34a 129 :************ : 12745000.red 12-20-00 2:24a 127 :************ : 12210000.red 12-20-00 3:20a 122 :************ : 12085000.red 12-20-00 4:11a 120 :************ : 04015000.red 12-20-00 5:01a 040 :**** : 03965000.red 12-20-00 5:56a 039 :*** : 05360000.red 12-20-00 6:52a 053 :***** :
The koth directory is doing better, 12 out of 21 warriors are scoring 120 or better, top score 127, low score 77 using the Franz test set. However a previous test performed just after the peak (first line of the above chart extract) shows all koth warriors scoring more than 119 with 6 scoring around 130. Notes.. the status scores in the chart are against the SF tiny warriors and are only roughly comparable with the Franz results (I think I'll switch to the Franz set for status too). Population size is 200, hill size specified as 20 (results in 21 warriors), duplication_rate from 0.5 to 0.2, soup battles set to 20, koth/testset battles set to 50.
Download Fizzle 1.2 for Windows (but it's a "dos" program) · last modified 9/30/03
This is a fairly simple evolver I wrote to try out a few ideas in the hopes of evolving stronger warriors. The name "Fizzle" describes what usually happens to soups of warriors, they tend to gather strength then stop improving at some point.
Fizzle features a fuzzy ring geometry using warriors numbered zero to population size minus one, a localness parameter controls how close the chosen warriors are to each other and varies from 0 for no topology at all to 1 for the nearest neighbor either way on the ring. Just about all the odds (instruction frequencies etc) are adjustable, the defaults were derived from analysing the Franz test set, a slightly old evolved hill and all the redcode in my RedMaker directory (mostly evolved) and averaging the results. The defaults for some odds like the rate of change ratios for various components are guesses. Most evolvers battle the selected warriors against each other, this one does too, but can also evaluate the warriors by battling them against test warriors rather than against each other. In "directed" modes the evolved warriors never fight each other. The fastest directed method randomly selects a test warrior to battle both selected warriors against, a more accurate but much slower method battles both chosen warriors against all of the test warriors, in effect using benchmark scores to drive the evolution process.
The documentation I wrote for Fizzle observes that once a population reaches a certain optimum, further improvements are not likely to occur due to the extreme luck a warrior form would have to have to survive a period of stategy change. This is mostly true (and qualified by observing that determining when the optimum is reached can be tricky) so I'll leave the docs alone for now, but I now observe that given a relatively strong form to work with, slow improvement does occur. The soup of papers I am presently evolving appeared at first to stop improving when it got to a SF tiny hill benchmark of about 127 but I let it run anyway. Each day is bringing about 2-3 points improvement, four days later it was up to a maximum of about 137. One factor I think helps is localness, when the selected warriors are close it allows weak code to self-improve more before being consumed, and maybe just maybe develope new tactics. Single-point changes (changing one thing on any given line) can only go so far, at that point (when improvement slows to a crawl) multi-point changes are required to yield further improvement. Localness increases the odds that a good multi-point change can be found, for example first a new instruction is tried but it makes the warrior weaker, but it is surrounded by other weak warriors to replicate over and find optimum data for the new instruction and in the end be stronger than the warriors before the instruction change. Fizzle also has an option that directly controls multi-point changes, if RND is less than multichance then another change is made to that line, making it possible to accidently create stronger code when multi-point changes are required. This appears to work only up to point, defined by the true (unknown) optimum of the dominent form and the likelyhood of changes required to effect improvement. After another day of evolution my soup is still at 137 peak. Fizzled.
9/30/03 - Fizzle 1.0/1.1 did well, producing a warrior which (luckily) placed first on the Sourceforge evolved hill, and after extended runs with a different soup produced warriors which benchmark around 150 against the evolved hill warriors, and the 140's against the Franz test set. Everything worked fine but the scoring function was unable to discern fractional-point differences, seems like that would get in the way of evolutionary fine-tuning. Practically it probably wasn't a problem but it bothered me, so decoupled the displayed score from the decision-making process and called it version 1.2.
10/10/03 - Fizzle warriors from an experiment that has been running for weeks. After several more days of evolution scores improved by 2-3 points but it is pretty much peaked, moving on. I found the Infinite Tiny Hill and picked 12 of the strongest warriors to make a test set (see TEST section for conversion batch), trying something...
Download the TEST benchmarker for dos\Windows · version 1.3 last modified 11/13/03
TEST requires pmars.exe or exhaust.exe (in the Fizzle archive) "on the path" and warriors to benchmark against such as the Franz test set for coresize 800 warriors or the Wilkies or Wilmoo test sets for coresize 8000 warriors. TEST is a menu driven program that benchmarks an entire directory of warriors against a directory of test warriors, warriors must have a ".red" extension. Core size can be set at 80, 800 or 8000 with any number of fixed or random rounds. Self-battle can be enabled to better predict hill results, or disabled for normal benchmarking. Settings are saved between runs and can be interrupted and restarted later to continue a benchmark. The bench process creates a report file containing scores, filenames and a bargraph version of the score with one * per 5 points. Menu options can (crudely) display unsorted and reverse-sorted (to make high-scorers come to the top) versions of the report.
To assist in converting warriors to a form suitable for Exhaust I created CONVRED.BAT (shift-clift to download), a batch file that converts all .RED files in the current directory into "load" format with no labels. To use, put the batch file in the same directory as the warriors to convert and run it. Simplified redcode is created in a directory named rcload and includes selected comments from the original code. Note... set up for coresize 800, edit the batch and change the numbers after set size= etc if converting warriors for other core sizes (don't change the part before=, just the numbers). The parameters must match any equivalent asserts present in the warriors being converted.
The batch files probably need minor tweeking to run on XP and other NT-like OS's, possibly due to syntax but more likely because of different rules regarding whether or not to leave an inactive window open, fixes for that involve inserting PAUSE into the batch code or setting up PIF files. QBasic.exe must be in a path directory to run batch files containing basic script.
In order to run any dos app and in particular the kind I tend to write, the msdos subsystem must be operational. Beware if you upgraded a 98 system to XP, when I did that the setup program applied my dos settings which were incompatible with XP but I didn't know that they were. It took some digging but eventually I found the autoexec.nt and config.nt files in C:\Windows\System32 directories and straightened things out. Find the dialog box that contains default environment variables, these are used when you launch a command prompt (whereas the .nt files are used when you start a dos exe). Disclaimer - I think, this is all very new to me. Programs running in a dos window flickered constantly until I made both the looked under default properties and made the buffer and screen size equal, both 80x25.
There seems to be a problem detecting single keystrokes when a dos program spends most of its time shelling other programs, I think Windows XP is assigning a different keyboard buffer to the shelled programs so keystrokes tend to fill up buffers that are never checked (again I think, that's how it behaves anyway). To fix this for now I added code to both Fizzle and TEST that detects if a file named "DeleteMe" is deleted. Using PMARS with TEST produces an ugly display under XP but otherwise works, the report looks fine. The messages compaining about missing asserts in the bench warriors go away after the first few warriors have been tested, don't know why but I'll take it - on second try no I won't, was killing the local environment in its attempt to be compatible and honor the ctty nul requests, causing the report viewing options to fail (no path). Oh well, no use hiding the assert warnings, changed TEST to use a more compatible shelling method. Funny the press Q to quit method is now working reliably, in fact everything seems smoother, as if XP adapted. Perhaps it did.
My LCC-compiled Exhaust works fine. The 386 version of PMARS does not work under XP, but one that does is here. Rename pmars_server.exe to pmars.exe and put in a path directory with the macro and sdl.dll file, and set the PMARSHOME environment variable to the directory containing the files.
Redmaker seems to (mostly) work ok under XP. There is an "Extended error" message that appears on the screen when evolution is first started (with both the 286 pmars and the "sdl" server pmars), eventually all but "Ext" is overwritten by growing warriors. The Ctrl-C stop method works. The path\nul method to check for the existence of a directory doesn't work, so it asks to create the initial population every time, Press N if you already have a soup in progress.
Redmaker 2.91 fixes the directory detection bug by checking for the existence of files rather than a directory. Under XP SP2 I no longer get the extended error using RedMaker 2.91 and SDL_pMARS however another version of pmars that used to work randomly failed (in text mode) after installing SP2. I had to redo all my warrior associations, something defaulted, stuff broke. To fix I had to specify the full path to my corewar helpers instead of just the command name, no longer "on the path" for Windows but RedMaker sees the path I set that included my utilities and runs well now.
Most of my old stuff was written for Dos/Windows/QBasic and standard MSDOS (6) batch. I have no defense except to say I chose the fastest programming route that worked for me because I'd rather spend my time evolving and trying to understand, not trying to understand a program language that I do not know. I know it sucks (from a language POV) but it gets the job done with a minimum of thought on my part. Figuring out the algorithms was hard enough. Now (1/9/05) I'm running Linux (Knoppix 3.6 on HD at the moment) and at first I felt the pain of my folly of not writing the tools in a more compatible language and did without CoreWar for awhile. Then I found DosEmu, a Dos Emulator for Linux. More accurately it emulates the dos interrupt calls allowing x86 dos code to run natively, so it's much faster than a real emulator but only runs on x86 machines. So if you have a standard PC with Linux and wish to run my evolvers and batch files, read on.
DosEmu has a limited function "dos" built-in but it isn't enough to run Redmaker or the batch file tools, you need at least FreeDos beta 9. To get things working I used KPackage (the KDE apt wrapper) to install dosemu and dosemu-freedos, manually downloaded dosemu-freedos beta 9 from http://www.dosemu.org/ and unpacked it to "freedos_b9" alongside the beta 8 freedos installed by apt, copied the dosemu directory from beta 8 to beta 9, copied all the dos stuff I wanted dosemu to see to MYDOS under home (including qbasic.exe), edited autoexec.bat to set up the drives like beta8 does, C: read only, D: home, and E: to a temp dir but added /MYDOS to the redirect command so dos won't see the whole home dir, also added a few directories to the path so things can be easily started, then edited dosemu.conf to specify a link to the freedos_b9 directory so it'll boot beta 9. At least that's what I had to do, your procedures will likely vary. Lots of doc-reading is required to get the most out of DosEmu but it is quite nice once set up.
DosEmu can be supplied a command to run then exit, this is the key to integrating dos tools into the Linux environment. A few Linux-native tools are available, including console and graphical versions of pmars if you compile them yourself (easy) but the majority of my new CoreWar redcode associations are provided by slightly modified versions of the batch files I've always used, including 5 variations of test.bat that tests the specified warriors against various benchmarks, and a right-click that simulates a hill challenge. To pull these tricks off I wrote shell scripts that extract the base name of the file to test, copy the warrior to a directory dos can see, call xdosemu with a command line that performs the desired action, then delete the file being tested from the dos directory structure. My test800e shell-script for example contains...
#!/bin/bash bn=`basename $1` cp -f $1 ~/MYDOS/args xdosemu "test800e d:\\args\\$bn" rm -f ~/MYDOS/args/$bn
This sets bn to the base name of the first argument ($1), copies the specified file to a directory dosemu/freedos is set up to see as D:\args (must exist), runs a batch named test800e.bat (must be "on the path") supplying the dos filename of the warrior to test, then deletes the file it added and everything exits. I modified test800e.bat for my local bench directory and to use list.com to display the results so it would remain on-screen, more/pause would work but the list utility is nicer. Once added as an association for *.red files all I have to do is right-click a warrior then select open with, test800e to bench a warrior with the evolved hill as a testset. Of course all this is specific to how your system is set up. For example.
In the case of the hill-sim battle.bat I had to get fancier. Battle.bat battles everything in the current directory against each other so I have to copy the target to the ~/MYDOS/CWSTUFF/battle directory alongside the test warriors but I don't want to overwrite a warrior of the same name. I ended up with a batch named dohill.bat on the dos path that CD's to D:\CWSTUFF\battle directory then runs battle.bat, and on the Linux side a dohill script containing...
#!/bin/bash bn=`basename $1` if [ ! -e ~/MYDOS/CWSTUFF/battle/$bn ]; then cp $1 ~/MYDOS/CWSTUFF/battle xdosemu "dohill" rm -f ~/MYDOS/CWSTUFF/battle/$bn fi
This variation does the cp/xdosemu/rm steps only if the file doesn't exist, otherwise does nothing.
DosEmu/FreeDos b9 is highly compatible with my qbasic and batch programs once I fixed RedMaker but the same fixes were also required for XP compatibility. The main difference I can tell (XP also) is there is no support for testing directory existence by looking for nul in the directory to test, anything that does "if not exist blah\nul md blah" or other variations has to be rewritten not to do this. Redmaker was the biggest offender and fixed, the other batches I use seem to work fine as-is except for the usual editing to tweek directories and make them stay on the screen instead of closing before I can read the output. The only thing not working is Fizzle but only because my self-compiled exhaust binary requires Windows, I need to recompile exhaust with something like Turbo-C for dos, or stick with pmars-based evolvers. Some versions of pmars and pmarsv don't work but the ones supplied in the standard (old) distro seem to work fine, even display graphically in a window, something I didn't have under Windows until recently.
Ok it's a crutch but for me a nice sturdy one! Eventually I'll start using native Linux scripts and programs to do some of what I do under dos, I'm sure it would be faster. But first I have to learn more about bash and sed and perl and C and... these things take lots of time but in the mean time I'm back to enjoying playing around with warriors.
3/11/05 - Finally a native Linux evolver, REBS. I'm not sure the bash scripting language is a step forward compared to Qbasic but at least I don't have to emulate to evolve and the script format makes it easier to tinker with the code. I'm still using the emulated dos tools to test the results but I'm having problems copying text from the emulated dos screen, I need to code my benchmarkers and hill simulator in bash to fix that.
The Redcode Evolver Bash Script for Linux requires pmars compiled without graphics, I used the pmars 0.8.6 source from the koth pmars page. Here are my x86 linux pmars binaries if needed. The pmars binary needs to be in a path directory (/usr/local/sbin here) or edit the script to specify the full path to pmars. To run the script, save the text to a filename besides rebs.txt (named that way to ensure web compatibility), mark as executeable, and edit first to make sure the parms are ok and you know what you're running. As coded REBS puts evolved warriors in a directory named "soup", uses a temp file named "evolver.tmp" and creates a file called "DeleteMe" to delete when you want it to stop. Don't interrupt the script using ctrl-c or other methods as that would likely leave corrupted warriors in the soup, delete the DeleteMe file to exit cleanly.
Although REBS was designed for Linux-like systems, Windows users can run the script without change under the Cygwin bash environment using a Dos or Windows (console) version of pmars.
The latest version-specific information and ramblings can be found on the REBS page.
REBS uses a simple algorithm: select two warriors, if a warrior doesn't exist create a random warrior in its place, battle the two warriors using pmars, copy the winner over the loser while making random changes, and do it again. Strings specify the instructions, modifiers and addressing modes with duplicate entries for weighting, probability odds control how often each of the six fields are modified, how often the end address changes, how often the warrior starts at the beginning vs some other address, chance of size change, chance of duplicate line and for data the chance the number will be a small +/- offset rather than a large positive number. Other chance variables that control how often data and the end number are incremented or decremented rather than replaced with a new random number when a change is called for. Which warriors are selected for battle is what defines the topology of the world the evolving warriors live in, and also how rapidly code forms can spread throughout the soup. Topology choices are none (random selection), a ring of warriors where each warrior can only battle its immediate neighbors, and a grid of warriors with side-side wraparound but no wrap top-bottom. Other options specify pmars parameters, core size, processes, cycles, rounds, how many warriors to create and other stuff. All configuration is done by editing the beginning of the script, once the program is going there is no interactive user interface besides deleting a file to stop it.
REBS uses an ANSI-based display where each character represents one warrior, making it easier to keep track of the soup. Assumes a black background. Change enableplot to 0 to disable the plot display and display only the status lines. When enableplot=1 ylines sets how many screen lines of warriors to display, xsize determines how many warriors are in each column line. When xsize is small the display is arranged into columns, mentally paste together. The total width is determined by how many columns are needed. The warriors are numbered from 0 at the top left corner and increment left to right, wrapping at the end of the column. Each warrior in the soup is represented by a single character displaying warrior length (A=10, B=11 etc) and colored according to species or length depending on the colormethod variable.
Ramdisk info...
REBS creates and deletes files constantly and like any file-based evolver should be run on a ramdisk. Creating a ramdisk is system-specific, for my HD installation of Knoppix I use something like...
sudo mkdir /mnt/rd # only needed once sudo mke2fs -m 0 /dev/ram15 sudo mount /dev/ram15 /mnt/rd sudo mkdir /mnt/rd/rebswork sudo chmod 777 /mnt/rd/rebswork
I chose /mnt/rd as the mount point for the ramdisk because it didn't exist and I wanted to keep all my mount points under /mnt but any directory will do. I chose /dev/ram15 because that was the highest ramdisk listed by ls /dev/ram* thus likely not to be used by anything else. Once a ramdisk and working directory on it have been created, copy the soup to evolve if one exists, change to the /mnt/rd/rebswork directory on ramdisk and run the REBS script. Delete the /mnt/rd/rebswork/DeleteMe file to stop evolution and copy the /mnt/rd/rebswork/soup directory back to hard disk to preserve the soup for the next run.
Under Cygwin install a ramdisk into config.sys or whatever method is appropriate for the version of Windows being used (XP requires installation of an XP-compatible ramdisk driver), then access under /cygdrive/x where x is the drive letter of the ramdisk. Copy the soup from hard drive to the ramdrive (if one exists), change to the ramdrive directory, run REBS and save the soup back to the hard drive when done.
To make things easier the necessary commands can be placed in a bash script. Another script that deletes the DeleteMe file from the ramdisk (rm /mnt/rd/rebswork/DeleteMe) can be used as a "stop button".
Modified March 16, 2005 - fixing links and stuff
Modified March 9 to April 8, 2005 (REBS, Linux notes)
Modified December 27, 2004 to January 9, 2005 (RedMaker 2.91, Compatibility
Notes)
Links fixed September 30, 2004
Modified August 30 to October 10 2003 (Compatibility Notes, Fizzle, TEST)
Modified April 7 2001 (RedMaker 2.85b)
Page created sometime in 1997