Maezumo - the Corewar Evolver with a Twist

Maezumo is Copyright Christian Schmidt and shared under the terms of the GNU Public License (v3). The packages on this page are configured for x86 GNU/Linux systems. The Windows version is at the Maezumo home page:

This page is for modifications, discoveries and thoughts about Maezumo. The materials here are my responsibility so if there are any problems or comments send them to me: Terry Newton (

Current Version

Maezumo_Linux_110.tar.gz - packaged 12/10/11 - 1.10 Fizmo version recompiled/packaged for Linux

Previous Versions

Maezumo_Linux_106cs.tar.gz - version 1.06cs 10/27/09 - takeover watcher options, hint mods
Maezumo_Linux_test106x17.tar.gz - version 1.06x17 4/18/10 - with additional reinsertion options
- previous 1.02x2b version (added stats and benchmarking)
Maezumo_Linux_103.tar.gz - previous 1.03x7 version (added soup display, hint mods)
Maezumo_Linux_104.tar.gz - version 1.04 8/3/09 - hint probability settings, benchmarking tools
Maezumo_Linux_test105x10.tar.gz - version 1.05(pre)x10 8/16/09 - nano hints, re-insertion mods

Random Thoughts

When developing things change, these notes will be edited as needed to preserve consistency. Previous notes, much of which no longer apply to more recent versions, have been moved to the unlinked maezumo_oldnotes.html file in this directory.

12/10/11 - Modified the 1.10 archive - fixed some of the file permissions, added a couple nano benchmark sets, changes to the readme including a note that libncurses5:i386 is required to run under 64-bit versions of GNU/Linux.

12/5/11 - Added a "stock" 1.10 version based on the Windows version (released 10/30/11) recompiled for Linux (at the moment no changes to source code which is dated 12/27/10). The Maezumo code is based a previous 1.06x16 version with a new optimize hint mode added to it (haven't tested it yet under Linux), the archive is based on 1.06x17 updated with the new 1.10 code. This is a brand new packaging so might need some tweaking...

4/18/10 - slightly modified the 'x17 archive - altered the nano, standard and tinylp INI files, removed the extra nano INI files (mostly redundant, scrounge around here for alternate settings) and added a few more notes to the readme.txt, mainly about how variable the process is but also a bit about running warriors in pmarsv from the browser.

4/16/10 - Trying something... added ReInsMode settings 6 and 7 to randomly select the reinsertion mode for each hill cycle. Mode 6 randomly selects modes 0 through 5, Mode 7 randomly selects between modes 3 and 5 (reinsert from the hill or from the species directory). Perhaps this might help avoid evolving "anti-high-score" warriors that sometimes occurs when reinserting only from topscore or species - mixing it up might help keep the soup warriors on their toes, exposing them to a wider variety of guiding code (both to compete against and to further mutate). Perhaps might help... it's an imprecise art that's often driven more by luck than the exact settings, and just because a given INI does well doesn't mean it'll do well again (for this reason the included INI's might or might not produce reasonable warriors, results will vary considerably).

The 'x17 version includes a few other things: Can now be recompiled for Windows or Linux without editing the source code, includes the LP tests sets from Fizmo's 1.06 archive and a new experimental tinylp INI (probably needs work), includes a new nanoht2 bench set that better mimicks the current SAL nano hill (at least with known code), and the bench.bas and rebench.bas programs now sort the report so that the highest scoring warriors are at the end.

4/9/10 - Found a minor bug in the soup display code I wrote - if the SoupDisplay setting was even (2 or 4) it didn't display the soup. This probably wouldn't be noticed under Windows as last I checked those unicode strings weren't supported anyway (so doesn't really matter there) but I noticed when I tried to use the narrow blocks option, now 1.06x16.

Sleepy Lepus (a paper made with 1.06cs) got KOTH at the Koenigstuhl Infinite Nano Hill (just barely). Nano 3551 (a paper from the 4/7/10 post below) got 6th place, and Little Red Rat (a stone made using a 1.04 proto, listed in the 8/1/09 post) got 4th place. Not bad. Here's Sleepy Lepus...

;name Sleepy Lepus
;author Terry Newton
;strategy evolved with -=< Maezumo >=- (1.06cs)
;strategy generation 269 of a hint-made paper
;strategy benchscore 156.32 (nanoBM07 1000 rounds)
;species name Nano 2302
;evolved:07:36:11 11-05-2009
;origin Paper 26
;generation 269
;assert CORESIZE==80
spl.b # 0 ,> 13
mov.i } -1 ,} 1
spl.b { 52 ,> 40
mov @ -5 ,{ -6
djn.x $ -1 ,< 46

...and here's the code for Paper 26 Generation 0 from which it evolved from...

spl.b  # 0 ,* -31
mov.i } -1 ,} 1
spl.b < 17 ,* 11
mov.i $ 26 ,{ -27
mov.i @ 32 ,} 30

This seed warrior scored 113 points against the nanobm07 test set. Top-score reinsertion was used to drive the score up, here's the INI file (has .txt extension for display purposes). Mutation didn't alter the code as much as with Frothering Foam (8/17/09 entry), just had to put a DJN at the end and rewrite most of the modes and numbers. The process still amazes me.

4/7/10 - The 106x15 test version is modified to include an option to reinsert previous warriors from the species directory, has an option to display the top score warrior in the HTML report, and includes a custom nano test set. The default INI is set to generate paper warriors for nano. I already had a 106x14 version with the new re-insert option from last year but hadn't really tested the mod, after reading the 1.06 announcement I dragged it out to give it a workout. The new re-insertion option is similar to the "Valhalla" process found in some other evolvers, when a re-insertion operation is triggered, it chooses a previous warrior that scores within a specified percentage of the current top score. The idea is to try to keep the soup scores from sliding backwards while maintaining diversity but as usual with a random process such as this, doesn't necessarily cause stronger code to be generated, just another thing to try. The 'x15 mod is a simple hack I made to keep from having to frequently open to see the current high-score, one of the side-effects of using re-insertion is it tends to evolve warriors to combat the re-inserted warriors, quickly driving top-scoring warriors from the hill.

Another technique I found useful when targeting the SAL nano hill was to use a custom benchmark set that scores published warriors similarly to their hill scores, 'x15 includes the nanoht1 test set I put together to sort of mimick the hill from early December of '09. The hill has changed since then so not sure how close it is now, back then it could predict hill score within around 4 points. To fine tune the test set I'd use a benchmark batch (a version of test800b.bat edited for nano) to see what warriors were affecting the scores for the known warriors, then alter the test set as needed to approximate the hill scores.

Here's a nano paper warrior generated using the new ReInsMode 5 option... [warrior comments edited]

;name Nano 3551
;author Terry Newton
;assert CORESIZE==80
;strategy evolved with -=< Maezumo >=- (1.06x15)
;strategy generation 236 of a hint-made paper
;strategy nanoht1 score 152, nanobm07 score 150
;evolved:06:08:24 04-07-2010
;origin Paper 6
;generation 236
;benchscore 152.47 (nanoht1 1000 rounds)
spl # 0 ,< 69
mov.i } -1 ,} 1
spl.b < 28 ,> 12
mov * 8 ,{ -5
djn.x $ 79 ,{ 45

For most of the run the settings were No of Koth=5, RItopPerc=95, ReInsChance=0.03, MutSelect=0.2, SoupIter=100. At the beginning of the run No of Koth was 3 ReInsChance was 0.01 but the re-inserted warriors didn't seem to be able to get a foothold, other warriors evolved to defeat them but those warriors didn't score particularly well. Even with the higher re-insertion rate the better-scoring warriors still tended to be driven from the hill but enough made the hill to push the top score up a bit more. Increasing No of Koth results in more failed benchmarks but seems to increase the odds of better-scoring warriors slipping past the anti-topscore warriors that often inhabit the top of the hill.

Looking at the evolved output, I see a couple of possible optimizations that could be made... but evolved code is supposed to be a bit weird and even though mov is the same as mov.i and for nano 79 is the same as -1, differences like that provide a good clue to determine what evolved from what so probably should leave that alone.

4/6/10 [edited] - Maezumo 1.06 has been released with improved hints and an option that enables and disables the hint probabilities to try to keep the hill more balanced rather than one type of warrior dominating the hill. I already had a previous version of 1.06 that Fizmo sent me, the program code (besides a few comment differences) is identical to the released 1.06 version and the port was ready-to-go, so tar-gz'd and posted. Fizmo's 1.06 package includes benchmark sets for LP warriors and alternate embedding code, not included in the 1.06cs version here. The default INI for this version is set for standard warriors with no mutation to demonstrate the new "takeover watcher" feature (it appears to be one of the original INI's for this version), alternate INI files included for nano, tiny, standard and X.

8/17/09 - Nano hints are fun, but mad mad bombers still rule the nano hill. The trouble seems to be the weaker SPL MOV MOV DJN [junk] form usually forms first, preventing the development of the (usually) stronger SPL MOV MOV MOV DJN or MOV SPL MOV MOV DJN forms. The only reliable solution to this [that I've found so far] is to watch the soup, if the weaker 4-line form takes over, start over (I use a script for this that deletes all .red files from the main, soup and species directories and deletes evo.ini, age.ini and warrior.ini). It often takes several tries before the superior form takes over. I seem to have more trouble with this effect than with other evolvers, the Maezumo soup seems to prefer the weaker form for some reason I haven't figured out yet. I suspect it has to do with the instruction and/or address mode weighting, and possibly due to not mutating the instruction modifier separately (although that's probably not it - other evolvers using a fixed instruction.modifier list have an easier time converging to the stronger form). Fundamentally Maezumo is a hint-driven evolver, as such the fixed instruction.modifier architecture cannot change without breaking the hints. This isn't really a problem, even though not originally designed for nano, Maezumo is perfectly capable of generating nano warriors that can take KOTH at SAL (and at the moment, Little Red Rat is in the #1 spot). That it's a bit finicky might be considered an advantage... we can probably do without hordes of effortlessly evolved warriors taking over the nano hill - it really should take work on the part of the user to make it happen. Yet the hacker in me still wants to either find better settings, or a modification, that naturally converges to the stronger form. More importantly, learn what it is that determines this. I have a feeling it's going to be a mod... likely in the form of custom instruction.modifier and address modes, which if specified replace the fixed tables (but in a way that doesn't affect the hints and so that, as with other mods, existing INI files still function the same). Sure this would give the user the power to generate totally incorrect redcode and a shower of errors, but that's OK if it's optional and gives advanced users the ability to specify the desired mix. [maybe... it'll probably won't happen very soon... despite having to restart it a few times to get it going in the right direction I'm quite happy with the current stock and experimental versions].

Ok back to experimental nano paper hints. Here is Frothering Foam...

;name Frothering Foam
;author Terry Newton
;assert CORESIZE==80
;strategy evolved with -=< Maezumo >=- v1.05(pre)x10
;strategy evolved:05:43:35 08-16-2009 as Nano 4873
;strategy generation 373 of a hint-made paper
;strategy nanoBM07 score 164, nanob2 score 146
;origin Paper 7
;generation 373
;benchscore 164.25 (nanoBM07 1000 rounds)
spl # 0 ,> 14
mov } -1 ,} 1
spl.ab < 53 ,< 18
mov $ 3 ,< -7
djn.f $ -1 ,< 47

This was made using the INI file in the 1.05(pre)x10 package, using re-insertion. It's not a perfect paper (when run in isolation it stops replicating before running out of cycles) but not too shabby. The really amazing part to me is that it evolved from this initial hint-made code...

spl.b  # 0 ,* -24
spl.b $ 24 ,{ 37
mov.i } -2 ,} -1
mov.i * -36 ,< 14
dat.f $ 0 ,$ 0

...totally different. I expected tweaked constants etc but evolution almost completely rewrote the code, greatly improving its strength, but somehow preserved its paperness. That blows me away. This isn't an isolated case, the previous x9 mod version using high-scoring hill warrior reinsertion produced this...

;name NanoWorms
;author Terry Newton
;strategy evolved with .=< Maezumo >=. version 1.05(pre)x9
;strategy 8/13/09 hill cycle 1226 paper hint generation 297
;strategy NanoBM07 score 159, nanob2 score 145
;assert CORESIZE==80
spl.b # 0 ,< -4
mov.i } -1 ,} 1
spl.b < 56 ,< 41
mov * 6 ,< 77
djn.f $ -1 ,< 48

...from this initial warrior code...

spl.b  # 0 ,{ 39
spl.b $ 10 ,* -31
mov.i } -2 ,} -1
mov.i { 26 ,< 15
mov.i @ -13 ,@ -33

In other news... I just got a brand new HP 110 mini sub-laptop with a 160 gig HD and HP's "Mi" brand of Ubuntu. Runs Maezumo perfectly :-) although I did have to use Synaptic to install libstdc++5 (and gcc-3.3-base) to get Blassic to work for the bench tools. I was a bit worried after reading something about having to recompile binaries (written about the older 1000 mini) but that doesn't seem to be a problem with this machine, just have to give plain x86 Linux binaries the libraries they need and they run. Not crazy about the consumer-grade interface skin but I do most of my work from the file manager and terminal anyway. Despite the prominent "terminal disabled" stuff on HP's web site it took all of 10 seconds to find it (press alt-F2 and type gnome-terminal) and another few minutes to add a terminal script to the nautilus-scripts directory so I can launch a terminal wherever I'm at. The Linux pmars/pmarsv binaries from my /cw/ list run fine (using the pmars[v]092N1 versions), should make a fine little evolving setup. Keeps the stuff from clogging up my desktop system's CPU... I've got real work to do :-)

8/16/09 - Posted a new 1.05(pre)x10 "experimental" version with better re-insertion options and a preview of Fizmo's new hints which now work even with nano. Consider the new hints a work-in-progress, but even like it is it's a pretty darn good work! For nano, the soup can be seeded with hint-made papers which then increase in strength through evolution to become much stronger than the initial papers. However they are still weak against "mad mad bombers" (like just about every nano warrior except other mad bombers) so unless steps are taken the soup will simply evolve warriors that defeat them or turn the papers into bombers. To counter this for the "x10" variation I added some code that copies the best-scoring warrior of the run to "" then added a new ReInsMode option to copy back to the soup instead of a hill warrior, so even if all the strong warriors get pushed off the hill it will still keep re-inserting the best-scoring warrior. Provided that warrior doesn't turn to stone, this keeps the soup from forgetting it's supposed to be evolving strong warriors. This option is similar to how the SEWAX evolver works so even without hints it should help to drive the benchmark score higher. This can lead to the "focus" effect where the evolved warriors do well against one set of warriors but not other warriors, so it's still a tricky thing... but not as tricky as it was in the x8 version where the strong warriors could simply be pushed from the hill, leading to a decrease in bench scores.

To make a Windows version of 'x10 get the Linux test version and extract it with an extractor that understands tar.gz files, get the stock 1.04 version from Fizmo's site and extract it (rename the directory to indicate 1.05), install FreeBasic, copy the files/maezumo.bas file from the Linux version to the base directory of the Windows version and rename it to say Maezumo105x10.bas, copy the files/embback.txt and files/embfront.txt files to the files directory of the Windows version (this is a new feature that allows embedding evolved warriors within other warrior code), copy over the updated faq.htm file and new INI file(s), edit the Maezumo105x10.bas file and change UseWin=0 to UseWin=1, open a command prompt in the Windows Maezumo directory and enter:

"c:\program files\freebasic\fbc" Maezumo105x10.bas

This should produce a Maezumo105x10.exe file.

[if needed the previous 1.04x8 experimental version is in the Maezumo_Linux_test104x8.tar.gz archive for now.]

8/4/09 - The re-insertion rate in the experimental version's INI seems to be too high... converged to weak SPL MOV MOV DJN forms in two consecutive runs. Backing off ReInsChance to 0.01 (with the present settings equivalent to about 13 soup battles per re-insertion) and reducing data change rate from 0.08 to 0.07 seems to be producing better results, converging more towards the much stronger SPL MOV MOV MOV DJN form, at least in this run. So why not just initialize it to the desired form to begin with? Well, tried that but it doesn't work well, evolution does not like to be forced. With only 5 instructions, nano warriors need to arise naturally so the interactions between the instructions form a unified whole and it resists attempts to interfere with the process. It seems that in the early stages of development, the desirable forms need the other forms to teach them how to be strong warriors.

8/3/09 - Updated to version 1.04 with new INI settings to control the probability for each hint mode when using hint mode 7 (all hints at once), this helps to control the mix of strategies on the hill. Fizmo's page now hosts the equivalent Maezumo 1.04 Windows version. To kick off the next round of experiments, the experimental "test" version adds a (sort of) "Valhalla" scheme where hill warriors are re-inserted back into the soup. One of the options is to re-insert higher-scoring warriors to (maybe) help drive up the strength of the soup, it doesn't always choose the highest scoring warrior but to help improve diversity each higher-scoring warrior on the hill has a 50% chance of being the one chosen for re-insertion. The effect of re-insertion is complex, the re-inserted warriors might replicate and strengthen to improve the scores (the intended effect), or the soup warriors might evolve strategies to defeat them but possibly score lower in the process and drive high-scoring warriors off the hill.

The previous .bas.tar.gz source-only file has been removed (for now)... it's easier to simply archive the latest experimental version. The source is in the files directory, to update a Windows version edit so that UseWin = 1 and recompile using FreeBasic - i.e. install FreeBasic, extract or open using an extracter that understands .tar.gz, copy the files/maezumo.bas file to the base directory of the Windows version along with the updated INI file(s) and faq, edit maezumo.bas and set UseWin = 1, open a dos prompt in the base directory and enter...

"c:\program files\freebasic\fbc" maezumo.bas

New features in experimental versions are subject to change or might have bugs (more so than the regular version), the experimental version is the test-bed for new ideas. Some ideas might not work out.

8/2/09 - Yesterday and last night's run with the 1.03x7 nano INI did fairly good, produced a warrior at hill cycle 2139 that scored over 150 on both nano test sets (152.5 and 155.2 using pmars -P). It was slow-going though, it took until about 1100 hill cycles before I started getting scores over 140. So to summarize... after 5 runs (that I saved) with these parameters, run 1 made a warrior at hill age 1352 that placed 2nd on nano, run 2 got stuck on a weak SPL MOV MOV DJN form and hadn't improved after almost 3000 hill cycles, run 3 made weak papers of the form of SPL MOV SPL MOV DJN and by about hill cycle 900 had mostly replaced them with bombers (but I had changed the INI to try to strengthen the papers... didn't work), run 4 settled into a potentially strong MOV SPL MOV MOV DJN form but by about hill cycle 1400 the best score was only 144 (might continue this run), and run 5 was last night's run that peaked over 150 after running a couple thousand hill cycles. For reference in case the settings get changed, this was with the following settings (plus usual nano settings with a hill size of 21)...

EnableSeed :0
MutByProb :0
MutSelect :1
MinChanges :0
SoupIter :100
SoupRounds :100
InstrRate :0.02
AddrRate :0.04
DataRate :0.08
SwapRate :0.01
InsertRate :0.01
DeleteRate :0
DupLine :0.2
IncDec :0.2
BigNum :0.6
Topology :0
SoupSize :1500
SoupX :50

8/1/09 - I discovered a new trick... if style="line-height:0.85;" is added to the pre tag just before the soup prints then the spacing between the lines is eliminated (and then some), this causes solid blocks to look much better and eliminates having to play with the background color etc. Like this sample output showing a 1500-warrior nano soup in a very early stage. A new version is in the works that has this and other enhancements, for now added the 'x7 changes to the current "experimental" 1.03 [version]. Also includes new nano settings which almost got a warrior named Little Red Rat to the top of the hill, lacked 0.1 points. So close. More interestingly, these settings also generated nano papers for part of one run, including these warriors...

;name Nano 390
;author Maezumo
;assert 1
;evolved with -=< Maezumo >=-
;evolved:20:12:20 07-31-2009
;origin Random 216
;generation 226
;benchscore 137.45 (nanoBM07 1000 rounds)
spl # 21 ,} 43
mov.i } -2 ,} 1
spl < 44 ,> 66
mov $ 21 ,< -5
djn.f $ -1 ,@ 65

;name Nano 590
;author Maezumo
;assert 1
;evolved with -=< Maezumo >=-
;evolved:22:26:57 07-31-2009
;origin Random 216
;generation 292
;benchscore 146.42 (nanoBM07 1000 rounds)
spl.x # 24 ,> 33
mov.i } -2 ,} 1
spl.a < 15 ,> 27
mov $ 55 ,< 55
djn.f $ -1 ,{ 43

The last warrior is losing its replicating ability, as the run progressed the papers were replaced by bombers (changing the INI settings while evolving might have caused that, I might have disturbed the balance). These warriors were made with a new version being tested but none of the pure mutation code was changed from the 1.03 experimental version so should be capable of producing similar results (maybe... every run is different).

A previous run with the new nano settings produced this mad bomber, which got 2nd place on SAL nano...

;name Little Red Rat
;author Terry Newton
;assert CORESIZE==80
;strategy evolved with -=< Maezumo >=- (1.04 proto version)
;strategy grid soup of 1500 warriors, hill age 1352 gen 847
;strategy nanbm07 score 153 Koenigstuhl-20(6/09) score 156
;evolved:21:31:30 07-30-2009
;origin Random 89
;generation 847
;benchscore 154.97 (nanoBM07 1000 rounds)
spl.x # -3 ,> 24
mov $ 1 ,< 1
mov > 51 ,> 19
mov @ 39 ,{ -3
djn.x $ -1 ,{ 61

The new grid soup and "swap lines" mutation options seem to work well, but pure evolution is a very random process, some runs produce strong results while other runs with exactly the same parameters produce weak results. Just like in nature... quite often the dominant form in a given environment is not the most intelligent one, and a relatively intelligent (high-scoring) species can be taken out by a simple core-stomper that does not rate well.

Evolving Stronger Nano Warriors With Maezumo (take II)

Originally Maezumo wasn't considered for evolving nano warriors, the original 1.00 version had an unnoticed bug that had to be patched to effectively evolve nano warriors at all. Version 1.01 is capable of producing strong nano warriors but finding them requires running an external benchmark program. Version 1.02 added automatic benchmark capability to make it easier to spot strong warriors, that helps but by itself is not enough, the strong warriors need to be re-tested against another benchmark set to find warriors capable of placing near the top of the nano hill. Version 1.02 and eventually version 1.03 (with new hints from Fizmo) was modified to allow using a grid-based soup which provided somewhat better diversity and added a soup display to see what was happening in the soup. Also added a new "swap lines" mutation operation which I found to be very useful with another small test evolver. To produce stronger nano warriors the settings needed to be adjusted so that good warriors could propagate through the soup without being disrupted too much, but with enough mutation to increase diversity and increase the chances of finding better warriors. Using the display, the parameters were set to generate warrior "islands" of about 20 to 200 warriors per instruction sequence, if mutation is too low then the same sequence will take over the soup, if mutation is too high then reasonably-sized islands don't develop and usually the warriors will be weak, unable to "remember" useful techniques. HTML can be tricky and displays differently depending on what browser is used, so the 1.03 version went through a few iterations in search of a better-looking soup display that worked equally well under Linux and Windows.

With the new mutation and visualization tools, Maezumo is now about as strong as any for making nano warriors provided the user is patient enough - it often requires several lengthy runs before really strong nano warriors are found, that's just the way an unguided pure evolver works... the warriors evolve to beat other warriors in the soup and on the hill, there is no guarantee that they evolve to please the human operator. One of the tricks is to set up the evolving environment so that it favors the production of desirable warriors. This requires careful adjustment of the mutation and other parameters, the nano INI file included with the latest 1.03 versions should be fairly close but there will probably always be room for improvement. Quite often a "lesser" form develops (like SPL MOV MOV DJN junk) and the warriors never get very strong, have to start over and try again. One trick to try is once a desirable warrior form is produced, increase the number of soup rounds, but that doesn't always work. Fewer soup rounds tends to produce more diversity due to the increased scoring error, which gives newly mutated warriors that would otherwise be wiped out a chance to further mutate into something stronger.

Once strong warriors are being produced, to do well on the nano hill the best warrior has to be selected. The latest versions include new benchmarking tools to help with that. The findtop program lists all warriors in the species directory that score within 95 percent of the highest detected score (according to the bench score comments), and outputs to a "topscore.txt" file. The rebench program reads topscore.txt and re-tests the warriors against another nano test set and outputs to another file, which can be sorted using the command-line sort utility so that the top scores appear at the end of the list. The better warriors will score high on both benchmark sets, so to select a warrior for the hill I find the warrior that has the highest score on both the nanoBM07 and the nanob2 (Koenigstuhl top 20) test sets. A warrior that scores very high on one but not so high on another usually won't do that well on the hill (even if the total of both benchmarks is higher). Since the nano hill content is unknown, the goal is to select a warrior that shows strength in general, not just against specific warriors in specific benchmarks. It may help to put together a custom benchmark that better imitates the hill contents but beware of warriors that score well on the custom benchmark but not others, they might initially post high but will drop in placement as the hill contents change. Warriors that score high against multiple test sets tend to maintain their placement better as new warriors are posted to the hill.

These are things I've noticed but there are no firm rules when it comes to a random process like pure evolving. For each observation there are likely exceptions... sometimes warriors do well despite scoring poorly against one or another benchmark, sometimes just picking the best-scoring warrior can gain good placement. Sometimes very strong code is produced on the first try, but it might take 10 tries. INI settings might work very well the first time, then never work well again. Other settings might be more consistent but only produce moderately strong warriors.

There are a few more tricks that could be tried... one is Valhalla where a warrior on the hill can be selected to put back into the soup. A variation would be to select the hill warrior with the highest benchmark score. Hmmm... but there could be adverse side effects from doing this. There's a chance that the inserted warriors will just keep the soup making the same thing rather than finding improvements. There's also a chance that the soup warriors will evolve to beat the inserted warriors but in the process not score well but instead just push the good-scoring warriors off the hill. There's one way to find out... later [added to the 1.04x8 experimental version].