Core War LLM Evolution Turns Adversarial Code Games Into a Self-Play Workbench

Building a testbed for adversarial program evolution

It is one thing to ask a language model to write a program. It is another to put that program into an adversarial environment where every candidate has to survive, reproduce, and defeat opponents. Core-War-LLM-Evolution is a Python project aimed at that second problem.

The repository implements an experiment framework inspired by Sakana AI's Digital Red Queen work. Its arena is Core War, the classic programming game in which compact assembly-like programs, called warriors, compete in shared memory. A warrior can try to outlast an opponent, overwrite its code, or copy itself to create more running processes. That makes the setting a compact, concrete way to study iterative program generation under competitive pressure.

The project will be most useful to builders who want to experiment with LLM-generated code in a simulator rather than evaluate it only by static inspection or a single test suite. It also offers a practical entry point for people curious about Core War and Redcode, without requiring them to build a virtual machine and evolutionary loop from scratch.

A champion must answer to its history

The central workflow is self-play. The README describes a progression that begins with seed warriors, including Imp and Dwarf. An LLM then proposes evolved warriors, while the system evaluates candidates in Core War battles.

The important constraint is historical competition. In the first evolutionary round, the aim is to produce a warrior that defeats the earlier champions. In later rounds, a new champion is expected to defeat the champions from all preceding rounds, not merely its immediate predecessor. The repository describes this as Red Queen dynamics: continuous pressure to adapt because the competitive target keeps accumulating.

That design addresses a familiar evaluation problem in competitive systems. A candidate that can exploit one opponent may look strong while remaining brittle. Requiring it to face an archive of prior champions is intended to push selection toward warriors that perform across a broader set of adversaries. The README characterizes the expected result as increasingly general and robust warriors, though it does not provide experiment results that would establish that outcome for a particular run.

The evolutionary process also incorporates MAP-Elites. MAP-Elites is a quality-diversity algorithm: instead of retaining only one best-scoring candidate, it preserves high-quality candidates across different behavioral categories. Here, its documented role is to preserve behavioral diversity during evolution. In a code-game setting, that matters because a single winning strategy can narrow search too early, while a diverse collection can retain alternative tactics for later rounds.

From Redcode parsing to battles and fitness

The repository's stated structure separates the experiment into focused pieces. The corewar area contains a Redcode parser and instruction set, a MARS virtual machine, and battle simulation. MARS, short for Memory Array Redcode Simulator, is the virtual machine that runs the competing warriors.

The documented Redcode reference includes operations for copying and arithmetic, control flow, comparisons, and process splitting. For example, MOV copies data, JMP changes execution flow, and SPL spawns another thread. These primitives give warriors a small but expressive vocabulary for tactics such as self-replication, bombing memory locations, scanning for enemies, or laying traps.

Above the simulator, the evolution area contains MAP-Elites and fitness evaluation. The main drq.py module is presented as the Digital Red Queen algorithm, while the LLM interface is organized by provider. The README lists Google Gemini, OpenAI, Anthropic, and local Ollama models as supported options. This separation is useful operationally: the competitive evaluation machinery is distinct from the component that requests candidate programs from a model.

The project also includes example warriors, identified as an Imp, Dwarf, self-replicator, scanner, vampire, and multi-threaded paper. Those examples make the domain less abstract. A new user can run a tournament over the warrior directory before attempting an LLM-backed evolution run.

Multiple ways to run and inspect an experiment

For a quick local check, the command-line runner offers a demo mode that the README says needs no API key. It also supports tournaments among example warriors. LLM-backed experiments can be configured with a provider, model, number of rounds, and number of generations. A Python API exposes the same core idea through DigitalRedQueen, a provider, and a DRQConfig object with parameters such as rounds, generations per round, and initial population size.

There is also a web interface launched with python app.py, documented to run locally on port 8080. Its advertised features include live fitness charts, logs, champion code viewing, a demo battle, and tournament mode. The visual layer is not just ornamental in this kind of work. Evolutionary runs can generate many candidates and rounds, so viewing fitness progression and inspecting the champion source can help a builder spot stalled search, surprising strategies, or changes worth investigating.

The project says it writes run artifacts to timestamped directories under drq_output. These include champion source files, per-round metrics, an experiment summary, and fitness-curve visualizations. Keeping code and metrics together is a useful practical pattern: an apparent improvement in fitness is easier to assess when the corresponding warrior can be inspected and replayed.

Useful constraints for builders

Two implementation choices are especially worth noting. First, the project provides both hosted and local model paths. Gemini, OpenAI, and Anthropic require their respective API-key environment variables, while the documented Ollama route is local and does not require a key. That gives experimenters a choice between provider-backed models and a local setup, with the usual tradeoff that model availability and behavior differ by provider.

Second, the historical champion requirement makes evaluation more demanding as rounds accumulate. That is a deliberate tradeoff. Testing against more prior champions can provide a stronger check against narrow counter-strategies, but it also means more battles to evaluate each candidate. The repository makes history length configurable, alongside generations and population size, so users can adjust that balance for their experiments.

Core-War-LLM-Evolution does not claim to settle how well LLMs evolve adversarial programs. What it provides is a concrete, inspectable environment for running that question: models generate warriors, a Redcode simulator runs the fights, an evolutionary process selects candidates, and artifacts expose what happened. Builders who want to explore that loop can inspect the repository at https://github.com/Taha-Tahiri/Core-War-LLM-Evolution.