I finished Core War Studio. It runs on Mac, iPad and iPhone, and it implements the whole ICWS '94 standard. But before I tell you what's inside, let me tell you why I did it, because the real reason is older than most of my code.

The game where you don't play
Core War is a game from 1984 where nobody plays. You write a tiny program in a language called Redcode, a friend writes another one, and both get dropped into the same chunk of memory. They run one instruction at a time, taking turns. If your program can't execute anything anymore, it's dead. Last one standing wins.
And that's it. Once the fight starts, you can't touch anything. No controller, no second chance. Everything you had to say, you said in the code, before the first move. After that you just watch and hope you got it right.
The smallest warrior ever, the Imp, is one line: MOV 0, 1. It copies itself one cell forward, forever. The Dwarf is only a bit longer and drops a "bomb" into every fourth cell of memory. Between those two, people have spent forty years inventing scanners, vampires, paper, stone and a whole zoo of other strategies.
I read the original 1984 article by A. K. Dewdney in Scientific American a few times now, and every time I come to the same conclusion: a surprising amount happened in 1984. I'll come back to that in another post, because I once gave a whole talk about it at Pixel Heaven.
I first saw Core War as a kid, in a magazine full of Macintosh screens. And I understood it, most of it anyway: programs that live, that attack each other, made of nothing but instructions. What I didn't have was a computer that could run it. A few years later I finally played with it on PC-DOS. Then it disappeared from my life.
The program on those magazine screens was the Macintosh version of Core War, written by Robert Martin in 1985. This is what it looked like:

It never really left, though. It stayed somewhere on the horizon as a memory of "core" programming, and the closest hook I could find was assembler. Did it push me toward programming? Maybe. I can't prove it. But it kept growing in me for a very long time.
Not invented from nothing
Dewdney was happy to admit the idea had ancestors, and the end of his article is my favourite part. There was a rumour about a program called Creeper spreading across a network and another called Reaper hunting it down. His verdict: the story was a mix of two real programs.
One was Darwin, a game from Bell Labs in the early 70s, where players' little assembly programs lived in memory together and tried to wipe each other out. Whoever had the most left at the end won. Its author even built an organism that couldn't be killed. It only won a few games. Immortal, but boring.
The other was Worm, from Xerox's research centre in Palo Alto: a program that moved into idle machines on a network, took them over and ran big jobs across all of them together, and stepped aside as soon as someone needed their computer back.
Put those two side by side and you get Core War. Dewdney ends with a dry joke: in Core War, Reaper has become reality.
It's assembly, just without the safety rails
If you've ever read a bit of assembly, Redcode will feel like home. No if, no while, no variables, no functions. Instructions, labels, jumps. This is the whole Dwarf:
ORG start
start ADD #4, bomb ; move the target 4 cells on
MOV bomb, @bomb ; drop the bomb there
JMP start ; and again
bomb DAT #0, #0 ; the bomb itself
The first version of Redcode had just nine instructions: eight that do something (MOV, ADD, SUB, JMP, JMZ, JMG, DJZ, CMP) and DAT, which holds data and kills any process that tries to run it. That's the entire language. You can learn it in an afternoon and still be discovering things years later. The ICWS '94 standard grew it to sixteen opcodes, but the spirit stayed the same.
What makes it different from real assembly is that someone removed the floor:
- No registers. Everything lives in one circular block of memory, 8,000 cells in the usual setup, and it wraps around at the end.
- Code and data are the same thing. Your program can rewrite itself, and rewrite the enemy. In normal programming that's a bug. Here it's the main weapon.
- Everything is relative. An address isn't "cell 4000", it's "four cells from here". So a warrior works wherever you drop it, and it can copy itself across the whole core and keep running.
- You can't stop. The closest thing to
HALTis stepping on aDAT. And a single warrior can split into dozens of processes withSPL, so even a twelve-line program can be its own multitasking operating system.
Nothing is hidden from you, and nothing protects you from yourself either. I learned things there that I only recognised years later in a debugger on a real machine.
Why I built this
The simplest reason: I went looking for a Core War app on macOS and couldn't find one. I looked on iOS and found nothing there either. So I did what programmers do and built it myself. And once I was building it, I wanted a proper workshop for the game, not just a simulator. Something where a newcomer can open a ready-made warrior, press play and understand what just happened, and where an old hand can step back through a fight one instruction at a time and see exactly where it went wrong.

So there's a Workshop with an editor, errors shown inline, an instruction reference, and your warriors saved as plain .red files you can see in the Files app. There's an Arena where you watch a fight on a live map of the core, or switch to Debug mode and step forward and backward, set breakpoints and inspect any cell or process. And there's a Compete area for matches, tournaments, benchmarks and local hills, all reproducible from a seed.
Underneath, the simulator follows ICWS '94 and I checked it battle for battle against pMARS, the reference simulator the community has trusted for decades. The engine and assembler are written from scratch, not ported, and they run a little faster than pMARS in my tests. No ads, no accounts, no tracking.
And now it's in my pocket
It took four evenings of researching, converting, programming, writing things down, setting up, fixing and testing. About 11,000 lines of Swift in the end: roughly 4,000 for the engine, 4,800 for the app and 2,300 for tests. And here it is.

Back then, watching a Core War battle needed a particular machine, a particular program and some patience. Today I can sit on a train, open my phone, drop two warriors into a core of 8,000 cells and watch them fight. Pause, step back, rewrite one, run it again, before my stop.

I don't think this will turn anyone into a programmer, and I'd be suspicious of any game that promised it. But I do think a few people will stumble onto it the way I did: a strange picture of programs fighting, impossible to forget. If it works on even one of them the way it may have worked on me, it was worth it.
If you've never heard of Core War, try it. Write an Imp. It takes one line.
Want to test it? The TestFlight group is open now, and it runs on Mac, iPad and iPhone. Just let me know: marcinrusinowski at gmail dot com.