Replicator Warriors

Replicator framework

A replicator is also referred as paper. Its ability to spread in the core and to disrupt opponent code is its main strength. By replicating and spreading, it assures itself a long endurance. The negative effect is it exposes and renders itself vulnerable to warriors that apply stun attack. Hence replicator is a formidable opponent against a single process stone and at the same time is an easy target against scissors-type warriors.

Basically, a replicator might look like this:

;name Paper 1 cnt EQU lst-src ; number of code in paper src DAT #cnt ; source pointer dst DAT #1222 ; destination pointer pap MOV #cnt, src ; #cnt is number of lines to be copied MOV <src, <dst ; copy a code... JMN -1, src ; once at a time and ; loop back until all lines copied SPL @dst ; split the process to a new copy SUB #23, dst ; give more distance to the next copy JMP pap ; make other copies lst END pap

At earlier time, this kind of warrior was also known as mice warrior. Against stones or dwarfs, they could easily overrun them.

;name Paper 2 cnt EQU lst-src ; number of code in paper src MOV #cnt, 0 ; source pointer MOV <src, <dst ; copy the code... JMN -1, src ; once at a time dst SPL @0, 1222 ; destination pointer SUB #23, dst ; give more distance to next copy JMZ src, src ; redo lst END src The second replicator doesn't need DAT for its pointers. Its pointers are used in double usages with others. Instead of replicating 8 lines of code, it now replicates 6 lines. This means smaller module and faster progress.


Like others, paper's goal is to terminate all of its adversary processes. Although it is lacking of what other warriors have: core-clear, it still can win just by mainly overwriting the opponent code with its own code. One hindrance with this is that simple plain of copying is not sufficient for paper to win alone. There is a chance that its adversary becomes converted into another working paper instead of getting clobbered. Thus, an ideal paper module should be able to self-terminate as well as to replicate. Here is the importance of checksum. It allows paper to check all the executing processes and direct their continuation. Those who can identify themselves as original paper's processes are allowed to continue replicating. Those who can't are forced to terminated.

One way to design checksum is by observing how distinct own processes from opponent ones when running in a paper module. They are:

Initial location.
The opponent process may start at anywhere in the copied module.
There are more processes executing the module (own's + opponent's).
A checksum can be implemented effectively with only few additional codes. The first warrior that demonstrates checksum is note paper.

The concept is as follow:

;name Paper 3 cnt EQU dt - src init SPL 1 MOV -1, 0 SPL 1 ; Create 6 on-line processes src MOV #cnt, 0 ; Init number of lines to be copied ; This also serves as a source pointer MOV <src, <dst ; Copy a line 6 times (make one full copy) dst SPL @0, #1222 ; Split 6 times MOV dt, <-1 ; Give more distance to next copy JMZ src, src ; Test for checksum MOV 0, -1 ; Attempt to erase that module dt END init The new warrior requires an initial set-up that creates 6 online processes. Down at the bottom is a neat single piece of code. It is intended for all alien processes. The checksum is such as in order to replicate successfully, there have to be exactly 6 processes running synchronously. Failing the requirement should trigger the self-erase routine at the bottom.