RedRace: Evolving Core Wars Page

Dave Hillis

    Welcome to the Red Queen's race (RedRace for short) where warriors must evolve as fast as they can just to stay in place. This page holds the source code for a version of my program for evolving core wars programs. It also has a windows executable intended to make it easy for people to join in a distributed project.

Last updated: 3/02/2001
* added some example evolved warriors
* reference to IMT#2
* more links
* new rev. of redrace :
- multiple populations can compete on the same hill
- compatible with exhaust v. 1.7
- can evolve warriors for different size cores without having to recompile
- more flexible parser for reading warrior files
- benchmark can include arbitrary number of warriors
- several minor changes - maybe improvements

    Core wars is a game in which virus-like programs battle each other for control of a virtual core memory space. It is an active game that started in the early 1980's and has on-line tournaments going on right now.
Go to the KotH site for information about core wars.
Go to Terry Newton's site for information about evolving core warriors.

    RedRace is a program that uses a genetic algorithm (GA) to evolve core wars programs, called
warriors, written in the Redcode language. A population of warriors competes in a game of king of the hill (KOTH) modeled after the ones at the KotH site where the fitness of a warrior (and hence it's chances of survival and of reproduction) is based on its score against the warriors currently on the hill. The fittest warrior of each generation is allowed to challenge the hill and attempt to dislodge the weakest warrior and replace it on the hill. The name is a reference to the race of the Red Queen in "Through the Looking Glass" by Lewis Carroll.

source code
parameter file
Windows executable


     This version of the program links in the “exhaust” simulator  written by M Joonas Pihlaja (may he live 1000 years!) which is protected under the GNU Public License. With the possible exception of the calling procedures for the exhaust routines, the code in redrace.c is not copyrighted. (If you get rich or famous re-using it, please let me know how you did it.)

Go to  to find out more about exhaust.

   RedRace is a C language program. I developed it by taking the program ga_war.c, written by Jason Boer  and gradually replacing it. I think of ga_war.c as an ancestral form.
     RedRace starts by randomly forming a population of individuals, each of which is a redcode warrior. The program then generates enough warriors to populate the hill (maximum of 50 warriors on the hill). Every generation, every warrior in the population competes (using the “exhaust” simulator) against each warrior on the hill and receives a fitness based on its composite score. The fittest warrior challenges the hill (it almost always gets on) and is immortalized - a copy is placed in Valhalla. Next the population gets scored against the changed hill and on and on it goes.
    The fittest warrior in the population will generally be exterminated within several generations because new warriors will have evolved specifically to defeat it and then made it onto the hill themselves. But warriors sent to Valhalla have a chance at resurrection each generation. A resurrected warrior may be able to thrive and reproduce again at some later time. Or conditions may never be hospitable enough for it to survive again.
    Optionally, the fittest warrior also battles an N warrior benchmark and this score is recorded. (Warriors in the benchmark must be named "",...,"" and be in a format that RedRace can read. I usually use the Wilkies benchmark.) The GA's fitness function is based on a hill whose members are constantly changing. Tracking the Wilkies score of the fittest member of each population gives an objective, (though of course, imperfect) measure of the progress (or lack of it) that the population is making.
      But watching the program run and waiting for a high Wilkies score would be very slow and disappointing. It's much more fun to follow the dynamics of what kind of warriors are getting onto the hill and how the warriors are changing over the generations. Depending on the settings, the file "" will hold a copy of the warrior that the program is testing at the moment. By opening another window from time to time and repeatedly running PMARS in graphical display mode with vs. a "SPL #0,  #0" you can see when a new kind of warrior emerges. On my own system, I have this set up as a kind of screen saver.
     Generally you'll see a bunch of core clears take over in the first few generations. Eventually, you should get something interesting: maybe replicators, maybe imp launchers, maybe scanners, ... . It may take a few days. You'll need patience, but you'll also need to decide when to pull the plug on a boring run and start over.

Getting Started

    You need to go to the exhaust site, read the license info. and download the source code. You may also want to get the PMARS software and the 12 warriors in the Wilkies benchmark (you can get these from the KOTH web site). You can compile redrace.c using the gcc compiler for UNIX. I compiled it for windows using "CodeWarrior Gold for windows 95/NT".
    If you have a Windows system, you should be able to just download the executable and run it. The file redrace.dat contains the run-time parameters along with what are intended to be descriptive comments. Make sure that you put it where the executable can find it.
    At first, it may be helpful to set the population and hill sizes (in redrace.dat) to  small values, like 6, and see what the program does for a few generations. A population size of 50 seems to work well for general experiments.
     The program opens a log file called "HAL0.log" which grows continually (keep an eye on it if you make very long runs). Each generation, the first 100 members of the population are written to files with names like "", and "", and the best warrior goes into a new file with a name like  "". Every generation, the best warrior will be written into a new "vl_.." file. It will save up to 300 of these files (modify this with the parameter "ringsize"). "" holds the warrior with the highest benchmark score encountered during the run.
    You can stop the program at any time by hitting CTRL-C. Then just restart it again when it's convenient. You won't have lost anything important and you don't necessarily need to change the redrace.dat file.
    To introduce a foreign warrior into an existing redrace population, the warrior must be written in a format that the simple parser in redrace can handle. The easiest way to do this is to run the new warrior (presumably a warrior from the distributed project) through PMARS to get the object code, then copy the new warrior into "" or one of the other files.

The Parser

*    Any line with a semi-colon (;) in it will be ignored entirely.
*    Blank lines or lines with no recognizable command will also be ignored.
*    P-space commands are not recognized.
*    Commands can be upper or lower case - but not mixed (e.g. don't use "SpL").
*    Start point can be assigned with "start" or "end" identifiers.
*    Labels are ignored.
*    Extra spaces between fields should not cause problems.

Distributed Project contains a number of young hills (on-line contests) where, for the moment at least, evolved warriors have a reasonable shot at getting on. The "Tiny" hill is dedicated entirely to evolved warriors. (The Tiny hill corresponds to the Baby hill at KotH.) The configuration (redrace.dat) file is configured to make warriors for this hill. You can evolve warriors using redrace or another evolver program and submit them to the Tiny hill to see how they stack up against other evolved warriors. But please no handwritten code - only pure evolved warriors! You can also download any warrior from the Tiny hill and make it one of your benchmark warriors or drop it into your local population and see if it can survive.

    The Tiny hill serves as the central hub of a distributed GA. Evolving warriors can migrate from computer to computer and even from evolver program to evolver program. But they need computers to run in and they need humans to serve as vectors of transmission by running the programs and submitting the warriors to the hill. Join now. BE A VECTOR!


This warrior won a mini tournament.
IMT #2 (October 1999)
;for a core size of 80
;author Dave Hillis
;strat -        Created with a GA.
; Ilmari's Mini-Tournament #2.
spl.i  #   -30, >    21
mov.i  *   -12, {     0
mov.i  >   -29, {    -2
djn.x  $    -2, $    -3
end   0

This warrior was recently on top of the Tiny hill.
;redcode-x verbose
;assert CORESIZE == 800
;name RedRace v1_163
;author Dave Hillis <>
;strat -   Created using RedRace.c.
;strat -   An evolving population playing KOTH.
;strat -   Configured for the Tiny hill.
  mov.i  >   268, }    -1
  spl.i  #   -75, }  -209
  mov.i  }    -3, }     1
  spl.i  >   299, {   211
  mov.i  }    -5, }    -1
  mov.i  $    -5, }  -375
  mov.i  {  -279, {    -6
  mov.i  #  -215, }    59
  mov.i  #  -215, }     3
  spl.b  #    19, <   275
  mov.i  *    55, }    -4
  mov.i  }   136, }    -3
  mov.i  #   358, }    -2
  mov.i  >   260, }    -4
  mov.i  }   397, }    -4
  mov.i  >   361, }    -5
  mov.i  }   268, }    -5
  seq.i  }   267, >    -8
  mov.i  >   358, <   371
  end   0

Warrior for a standard size core - imps
;redcode-b verbose
;assert CORESIZE == 8000
;name redrace_6_08_00
;author Dave Hillis
;strat -        Created using RedRace.c.
;strat -        An evolving population playing KOTH.
;wilkies = 128
;wilmoo = 102 # -3737, @     8
spl.i  #  3823, { -2469
add.i  # -3748, @     1
mov.i  # -2082, }     1
spl.i  $    -4, *     1
jmp.x  *    -1, <    -5
end   4

Paper for a standard sized core
;assert CORESIZE == 8000
;name red_race/
;wrapped around once
;wilkies = 95
org     S;
mov.a  }  -499, >  8262
seq.i  < -2781, > 11909
cmp.i  @   546, <  3885
sub.i  > 10896, {     0
spl.i  #   147, *    -3
spl.b  >  3251, } -1369
mov.i  }  1611, < -1137
mov.i  <    -6, <  1306
spl.i  #  2951, }     2
mov.i  }   -11, }    -4
mov.i  >   739, {  -133
mov.i  *   -10, }    -7
mov.i  $    -2, {    -4
djn.i  >  2319, {  4178

More Links

 John Perry: Core Wars Genetics: The Evolution of Predation
 Ryan Coleman: Learning By Simulating Evolution Using Corewars
George Lebl: sys4
 Terry Newton: RedMaker, lots of info.
 Jason Boer: ga_war.c
Martin Ankerl: YACE (Yet Another Corewar Evolver)
 Ilmari Karonen's page
 The Pizza server: more core wars hills and info


       Evolving core warriors is the coolest technical thing that I have ever encountered, and I've worked on some pretty cool stuff over the years. I encourage you to try it , if you haven't already. Re-use as much code and ideas as you can and concentrate on new techniques. To get from the present state of the art to pure evolved warriors that are as good as hand written ones will require a lot of creativity.

  I think that techniques for evolving core warriors also apply to many practical problems. I modified redrace to work on  a battle planning problem and was pleased with the results. (I guess I should add the conference paper sometime...)

    This is the second release of redrace. I'm sure that the program has bugs and that it's unnecessarily confusing. If you send me questions or comments about it, I'll be glad to know it's being looked at and try to help.


    I would like to thank Martin Ankerl, Jason Boer, Ken Espiritu, Terry Newton, and M Joonas Pihlaja (in alphabetical order) for their contributions to this effort, and the too-numerous-to-mention core wars folks who distribute the PMARS program, maintain the web sites and tournaments, publish their handwritten warriors and generally keep core wars a living game.

If you have comments or suggestions, email me at