Embedded Core War battles

Core War

Core War is the grandaddy of programming games. If you date it from the initial article in Scientific American which effectively started the whole phenomenon then it’s 30 years old this year.

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.

And, by steering clear of external dependencies, it’s pretty easy to compile as ClojureScript as well so we can run and visualise battles in the browser. (It’s not the first time this has been done, obviously. There’s at least one JavaScript MARS implementation out there.) I think a lot of the Core War literature would be much easier to assimilate if battles were embedded in the pages to illustrate the behaviour of the warriors under discussion.

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.

See corewar.co.uk for a really good collection of Core War resources. (It’s actually part of a web ring too - remember those?)

I’ll release the ClojureScript code if and when there’s anything worth looking at or anyone wants to look. The component above is just a few bits of Om and core.async strung together. As well as obvious improvements to the visualisation, to be a useful means of embedding battles in web pages this would need to offer a sensible JavaScript API and accept warrior definitions as redcode (embedded or sourced elsewhere).

Comments