Editing Core War (section)

== Gameplay ==
At the start of a match, each warrior is loaded into a random memory location. Programs take turns executing one instruction at a time. A program wins by terminating all opponents, typically by causing them to execute invalid instructions, leaving the victorious program in sole possession of the machine.

Early versions of Redcode featured only eight instructions. This number increased to 10 in the ICWS-86 standard, 11 in ICWS-88, and 16 in the 1994 draft standard, which is still widely used. With various [[addressing mode]]s and instruction modifiers introduced in the 1994 draft, the total number of possible operations is 7168. Redcode does not define how instructions are represented in memory, nor does it allow programs to inspect their own code structure beyond copying and equality comparisons. Arithmetic operations are limited to the instruction’s two address fields.

;Constant instruction length and time: Each Redcode instruction occupies exactly one memory slot and takes exactly one cycle to execute. The rate at which a process executes instructions, however, depends on the number of other processes in the queue, as processing time is shared equally.

;Circular memory: The memory is addressed in units of one instruction. The memory space (or ''core'') is of finite size, but only [[relative address]]ing is used, that is, address ''0'' always refers to the currently executing instruction, address ''1'' to the instruction after it, and so on. The maximum address value is set to equal one less than the number of memory locations and will wrap around if necessary. As a result, there is a one-to-one correspondence between addresses and memory locations, but it is impossible for a Redcode program to determine any absolute address. A process that encounters no invalid or jump instructions will continue executing successive instructions endlessly, eventually returning to the instruction where it started.

;Low-level multiprocessing: Instead of a single [[instruction pointer]] a Redcode simulator has a ''process queue'' for each program containing a variable number of instruction pointers which the simulator cycles through. Each program starts with only one process, but new processes may be added to the queue using the <code>SPL</code> instruction. A process dies when it executes a {{mono|DAT}} instruction or performs a division by zero. A program is considered dead when it has no more processes left.

;No external access: Redcode and the MARS architecture provide no input or output functions. The simulator is a closed system, with the only input being the initial values of the memory and the process queues, and the only output being the outcome of the battle, i.e., which programs had surviving processes. Of course, the simulator may still allow external inspections and modification of the memory while the simulation is running.

===Versions of Redcode===
A number of versions of Redcode exist. The earliest version described by [[A. K. Dewdney]]<ref name=dewdneycwg/> differs in many respects from the later standards established by the International Core War Society, and could be considered a different, albeit related, language. The form of Redcode most commonly used today is based on a draft standard submitted to the ICWS in 1994 that was never formally accepted, as the ICWS had become effectively defunct around that time. Development of Redcode, however, has continued in an informal manner, chiefly via online forums such as the <code>rec.games.corewar</code><ref>{{cite web|url=https://groups.google.com/g/rec.games.corewar |title=rec.games.corewar on Google Groups |access-date=2023-05-29}}</ref> [[newsgroup]].

===Strategy===
Warriors are commonly divided into a number of broad categories, although actual warriors may often combine the behavior of two or more of these. Three of the common strategies (''replicator'', ''scanner'' and ''bomber'') are also known as [[Rock paper scissors|paper, scissors and stone]], since their performance against each other approximates that of their namesakes in the well-known playground game.<ref name=wangsaw>{{cite web|url=https://corewar.co.uk/mintard/index.htm |title=Intro to Art in '88: Paper - Stone - Scissors Trilogy |access-date=2023-05-27 |last=Wangsaw |first=Mintardjo}}</ref>

;Paper (or replicator): A replicator makes repeated copies of itself and executes them in parallel, eventually filling the entire core with copies of its code. Replicators are hard to kill, but often have difficulty killing their opponents. Replicators therefore tend to score a lot of ties, particularly against other replicators.
:A '''silk''' is a special type of very rapid replicator, named after ''Silk Warrior''<ref>{{cite web|url=https://asdflkj.net/COREWAR/94/HILL32/silkwarrior13.red |title=Silk Warrior 1.3 |access-date=2025-03-02 |last=Pohjalainen |first=Jippo}}</ref> by Juha Pohjalainen. Most modern replicators are of this type. Silk replicators use parallel execution to copy their entire code with one instruction, and begin execution of the copy before it is finished.<ref>{{cite web|url=https://groups.google.com/g/rec.games.corewar/c/D2q6OlEnXUo/m/9On9BfVvmU0J |title=replicators? -> Phoenix & TimeScapesource |access-date=2023-05-27 |last=Pohjalainen |first=Jippo |date=April 1995}}</ref>

;Scissors (or scanner): A scanner is designed to beat replicators. A scanner does not attack blindly, but tries to locate its enemy before launching a targeted attack. This makes it more effective against hard-to-kill opponents like replicators, but also leaves it vulnerable to decoys. A scanner usually bombs memory with {{mono|SPL 0}} instructions. This causes the enemy to create a huge number of processes which do nothing but create more processes, slowing down useful processes. When the enemy becomes so slow that it is unable to do anything useful, the memory is then bombed with {{mono|DAT}} instructions. Scanners are also generally more complex, and therefore are larger and more fragile, than other types of warriors.<ref>{{cite web|url=https://corewar.co.uk/metcalf/scanner.htm |title=Anatomy of the Scanner, A Basic Introduction |access-date=2023-05-27 |last=Metcalf |first=John |date=April 2004}}</ref>
:A '''one-shot''' is a very simple scanner that only scans the core until it finds the first target, and then permanently switches to an attack strategy, usually a core clear. ''Myrmidon''<ref>{{cite web|url=https://asdflkj.net/COREWAR/94/HILL32/myrmidon.red |title=Myrmidon |access-date=2025-03-02 |last=van Rijn |first=Roy}}</ref> by Roy van Rijn is an example of a oneshot.

;Stone (or bomber): A bomber blindly copies a "bomb" at regular intervals in the core, hoping to hit the enemy. The bomb is often a {{mono|DAT}} instruction, although other instructions, or even multi-instruction bombs, may be used. A bomber can be small and fast, and they gain an extra edge over scanning opponents since the bombs also serve as convenient distractions. Bombers are often combined with imp spirals to gain extra resiliency against replicators.

;Vampire (or pit-trapper): A vampire tries to make its opponent's processes jump into a piece of its own code called a "pit". Vampires can be based on either bombers or scanners. A major weakness of vampires is that they can be easily attacked indirectly, since they must by necessity scatter pointers to their code all over the core. Their attacks are also slow, as it takes an extra round for the processes to reach the pit. ''myVamp''<ref>{{cite web|url=https://asdflkj.net/COREWAR/94/HILL32/myvamp37.red |title=myVamp v3.7 |access-date=2025-03-02 |last=Paulsson |first=Magnus}}</ref> by Paulsson is an example of a vampire.

;Imp: Imps are named after the first ever published warrior, ''Imp''<ref>{{cite web|url=https://asdflkj.net/COREWAR/88/HILL32/imp.red |title=Imp |access-date=2025-03-02 |last=Dewdney |first=A. K. |author-link=A. K. Dewdney}}</ref> by [[A. K. Dewdney]], a trivial one-instruction mobile warrior that continually copies its sole instruction just ahead of its [[instruction pointer]]. Imps are hard to kill but next to useless for offense. Their use lies in the fact that they can easily be spawned in large numbers, and may survive even if the rest of the warriors are killed.
:An '''imp ring''' (or '''imp spiral''') consists of imps spaced at equal intervals around the core and executing alternately. The imps at each arm of the ring/spiral copy their instructions to the next arm, where it is immediately executed again. Rings and spirals are even harder to kill than simple imps, and they even have a (small) chance of killing warriors not protected against them. The number of arms in an imp ring or spiral must be [[coprime|relatively prime]] with the size of the core.

;Quickscanner (or q-scan): A quickscanner attempts to catch its opponent early by using a very fast unrolled scanning loop. Quickscanning is an early-game strategy, and always requires some other strategy as a backup. Adding a quickscanning component to a warrior can improve its score against long warriors such as other quickscanners. However, the unrolled scan can only target a limited number of locations, and is unlikely to catch a small opponent.

;Core clear: A core clear sequentially overwrites every instruction in the core, sometimes even including itself. Core clears are not very common as stand-alone warriors, but are often used as an end-game strategy by bombers and scanners.

===''Core War'' Programming===
With an understanding of ''Core War'' strategies, a programmer can create a warrior to achieve certain goals. Revolutionary ideas come once in a while; most of the time, however, programmers base their programs on already published warriors. Using optimizers such as OptiMax or core-step optimizer tools, a more effective warrior can be created.

Warriors can also be generated by [[genetic algorithm]]s or [[genetic programming]]. Programs that integrate this evolutionary technique are known as ''evolvers''. Several evolvers were introduced by the ''Core War'' community and tend to focus on generating warriors for smaller core settings. The latest evolver with significant success was ''μGP''<ref>{{cite web|url=https://github.com/squillero/microgp2/ |title=μGP (MicroGP v2) |access-date=2018-09-10 |last=Squillero |first=Giovanni |website=[[GitHub]]}}</ref><ref name="q133">{{cite journal | last=Corno | first=F. | last2=Sanchez | first2=E. | last3=Squillero | first3=G. | title=Evolving Assembly Programs: How Games Help Microprocessor Validation | journal=IEEE Transactions on Evolutionary Computation | volume=9 | issue=6 | date=2005 | issn=1089-778X | doi=10.1109/TEVC.2005.856207 | pages=695–706 | url=https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=6026078bb5915689d4a4efcc26d541617f53182a}}</ref> which produced some of the most successful nano and tiny warriors. Nevertheless, evolutionary strategy still needs to prove its effectiveness on larger core settings.<ref>{{cite web|url=https://corewar.co.uk/vowk/alife9ac.pdf |title=An Evolutionary Approach Generates Human Competitive Corewar Programs |access-date=2023-05-27 |last=Vowk |first=Barkley |author2=Wait, Alexander |author3=Schmidt, Christian}}</ref>