Competing programs (written in rather an esoteric assembly code - “redcode”) battle for control of a memory space (in the “MARS” - Memory Array Redcode Simulator) by bombing or trapping each other while trying to evade enemy fire and replicating themselves around the MARS. A warrior wins if all its opponent’s processes die (by executing an “illegal” instruction - i.e. DAT or divide by zero).
These programs (or “warriors”) get pretty complex and there’s a hard-to-penetrate terminology that’s used to describe and analyse them. I’m not sure how many beginners enter the fray anymore.
A thriving early ecosystem with weekly newsletters seems to have died down these days - the various forums don’t see much activity. I’m sure it’s alive and kicking but from the outside it certainly has the charming aura of a community whose heyday is behind it.
Despite this, there are a lot of hits on GitHub and the main “hills” are still open for business although again there’s not much activity and there is a notably narrow selection of authors represented.
I think it’s long overdue a resurgence but I’m not sure what would kickstart it. It’s entirely possible more people are interested in writing MARS implementations than warriors to fight in them…
Despite which, for a bit of fun I hacked out a quick Clojure implementation of the ICWS94 Draft standard the other day. So far at least, it’s only an implementation of the interpreter (not the assembler) and it doesn’t implement the PSpace feature yet.
Imp vs Dwarf
Just for starters, here’s a slow motion battle between the two original archetype warriors, an imp (that copies itself forward through the core) and a dwarf (or stone) that bombs core at intervals of four instructions.
Without an assembler, it’s a bit of a pain to load up sophisticated warriors right now which is a shame because these two are a poor representation of the weird and wonderful Core War menagerie that’s evolved over the past thirty years. There are scanners and vampires and replicators and so on.
This isn’t much of a battle. Imp cannot win - if it overwrites the dwarf, the dwarf becomes an imp, executing the copy forward instructions itself forever. The result is a draw after a limited number of cycles have passed. Dwarf can get lucky and bomb the imp at the cell at which it’s about to execute in which case the result is a victory for the dwarf.
This is a crude visualisation that doesn’t indicate which programs are executing where - it just colours the cells by the type of instruction they contain so you can see the code changing as the programs execute. pMARS and other simulators use colour to distinguish the different warriors instead which gives a better idea of who’s doing what. Other drawbacks: it doesn’t display the results and it doesn’t show any activity at all if instructions aren’t changing. Still, it’s a start.