Subject: Re: No bombers here. From: wms@iwarp.intel.com (William Shubert) Date: 1 Feb 92 00:15:49 GMT Message-ID: <1992Feb1.001549.12085@iWarp.intel.com> While commenting on the KotH hills, Andrew Pierce (ajpierce@med.unc.edu) wrongly assumed: >Any larger progs >which try to get fancy dramatically increase their effective target size >and since it only takes one hit in any active prog with a spl bomb to >render the whole thing useless, these don't have a chance. Wrong. The #1 program on the standard hill, "Sleepless 1.2", is in fact very long and the entire piece of code is executed frequently. >Conversely, >for the experimental hill, where the spl bomb is no more effective than a >dat bomb, it seems that all progs would be of the mice type variety, >trying to replicate themselves as quickly as possible so that they could >never be completely destroyed. Wrong again. The experimental hill is about half mice-like programs and about half one-process-thread programs. Leech does OK here; it's number three right now. Better than mice, in fact, seems to be programs which do replicate, but do it intelligently. Simple mice-like programs apparently end up running too slowly to achieve much of anything and rapidly get destroyed by vampires; although the vampires can't split the captured processes to capture huge amounts of time, if enough processes are captured they can still win. I must admit, I am impressed with both hills - I never would have expected that some of the programs that have shown up on the standard hill would have performed well at all, but they did. The experimental hill has been doing OK, but I'm not sure if the programs present there are all that much more interesting than the standard hill. However, I do plan on trying out other rules variants - in particular people seemed to want to try setting the maximum write distance. Before I make any changes, however, I'd like to get KotH usable for things besides a tournament so that people can try out ideas for experimental hill before they submit them. -Bill (wms@iwarp.intel.com) Subject: Re: No bombers here. From: ASMQK@ASUACAD.BITNET Date: 1 Feb 92 01:56:45 GMT Message-ID: <92031.185645ASMQK@ASUACAD.BITNET> Csapda (the first in the experimental hill) is a jmp bomber. Path: overload.lbl.gov!agate!ames!elroy.jpl.nasa.gov!usc!wupost!darwin.sura.net!gatech!mcnc!samba!ajpierce From: ajpierce@med.unc.edu (Andrew Pierce) Subject: Crobots Tournament From: Date: Saturday, 1 Feb 1992 11:51:35 EST Message-ID: <92032.115135JJJ101@psuvm.psu.edu> Here are the 10 entries in the tournament. It will be round robin, with each unique foursome fighting 20 times. I will probably run 4 rounds, with each round consisting of 5 fights per foursome. I will post each round's score. James Below are the contestants: //Steve Patrick //steve@bradley.edu //Cruiser //cruiser.r //Gary Haussmann //haussman@ucsu.colorado.edu //Fred 1.0 //fred.r //J. Pekkanen //k39645n@saha.hut.fi //HeatSeeker 1.8 //heatseek.r //Eugene Hu //eugene@locus.com //Hitnrun //hitnrun.r //Ray Cromwell //rjc@gnu.ai.mit.edu //Marksman V2 //marksman.r //Chris Beauregard & Royce Vaughn Fay //cpbeaure@descartes.waterloo.edu //Seeker v1 //SEEKER.R //James Jesensky //jjj101@psuvm.psu.edu //Stush Version 1.0 //stush-1.r //Ray Cromwell //rjc@gnu.ai.mit.edu //Ambush //ambush.r //David Richter //darichte@rnd.stern.nyu.edu //Trial 4 //trial4.r //Greg Bailey //trmarks@uokmax.ecn.uoknor.edu //RUNGUN //rungun.r Subject: Crobots Tourny: ROUND 1 RESULTS From: Date: Saturday, 1 Feb 1992 14:58:02 EST Message-ID: <92032.145802JJJ101@psuvm.psu.edu> Here is the results atfer Round 1. There are still 3 rounds left to be played. (The final score is the sum of round 1, round 2, round 3, and round 4. All 4 rounds are identical.) To obtain the HUGE output file from round 1, mail to jesensky@endor.cs.psu.edu Current Score After One (1) Round of Play Author(s) Program Score --------- ------- ----- Chris Beauregard & Royce Vaughn Fay Seeker v1 1104 James Jesensky Stush Version 1.0 756 Eugene Hu Hitnrun 717 Steve Patrick Cruiser 261 Greg Bailey RUNGUN 222 J. Pekkanen HeatSeeker 1.8 39 Ray Cromwell Marksman V2 27 David Richter Trial 4 9 Ray Cromwell Ambush 6 Gary Haussmann Fred 1.0 6 *END* From: JJJ101@psuvm.psu.edu Subject: Stush-1.r Message-ID: <92032.111707JJJ101@psuvm.psu.edu> Date: 1 Feb 92 16:17:07 GMT //James Jesensky //jjj101@psuvm.psu.edu //Stush Version 1.0 //stush-1.r /* Move around like a bouncing ball at max. speed possible. Scan for targets. When a target is found, continually fire at it. If it disappears, scan to the left and right of last know location. This does nothing fancy. I want to see how it does against more elaborate programs. */ main() { int d,old; int x; int y; int flag; d=45; old=45; flag=1; while(1) { if (d!=old) { drive(d,49); old=d; } else drive(d,100); x=loc_x(); y=loc_y(); if (x<100 && d==135) d=45; if (x<100 && d!=45) d=315; if (x>900 && d==45) d=135; if (x>900 && d!=135) d=225; if (y<100 && d==315) d=45; if (y<100 && d!=45) d=135; if (y>900 && d==45) d=315; if (y>900 && d!=315) d=225; if (flag) { if (s=scan(f,10)) cannon(f,s); else if (s=scan(f+20,10)) f+=20; else if (s=scan(f-20,10)) f-=20; else flag = 0; if (s=scan(f,10)) cannon(f,s); } else { f+=85; if (s=scan(f,10)) { cannon(f,s); flag=1; } } } } Subject: Re: No bombers here. From: cedman@714-725-3177.nts.uci.edu (Carl Edman) Date: 1 Feb 92 18:09:09 GMT Message-ID: <298AE245.15177@orion.oac.uci.edu> The solution to this problem is - of course :-) - to: a) To split the CPU slice of the parent between both children b) To permanently lose the CPU slice of a killed process This strikes a nice balance between a) traditional games where a single split bomb can completely take out your side and hence the reduction of a programs exposure to bombs is the overriding prerogative and b) games in which process time is split between the children but the CPU slice is redistributed upon death of a process where being hit by a bomb becomes completely irrelevant as it doesn't really hurt you and the increase in your number of processes (which makes you harder to kill) becomes the most important consideration by having c) games in which being hit by a bomb (any type) is something which you want to avoid (as your side permanently uses a share of processing power) without making such a hit the end of the game for one side or the other. I suspect that even if these rules were implemented there might still be a tendency to split as much as possible as a single survivor can at least guarantee a draw. Two solutions: a) Make draws even less valuable b) Allow a victory not only by knock out also by points i.e. if at the end of the game one program retains more than 4 (8 ? 16 ?) times as much of its CPU slice as its opponent it will be considered a technical victory for that program Carl Edman Subject: Re: No bombers here. Message-ID: <1992Feb1.190940.18916@samba.oit.unc.edu> Date: 1 Feb 92 19:09:40 GMT In article <1992Feb1.001549.12085@iWarp.intel.com> wms@iwarp.intel.com (William Shubert) writes: > Wrong. The #1 program on the standard hill, "Sleepless 1.2", is in fact >very long and the entire piece of code is executed frequently. Yes but how does it score against the spl bombing type programs? It seems to me that such a program would get massacred by say, Sargent which specifically hunts out large programs and then bombs them with jumps to a split routine. (Does anyone know who wrote Sargent btw? Nice prog.) The overall type of program on the hill seems to evolve in a cyclical fashion over time (at least from looking at the strategy lines). Are spl bombers currently rare on the hill? (It might be time for a resurgence.) That is interesting about Sleepless 1.2 though. Maybe things aren't really as cut-and-dried as they seem. -Andy ajpierce@med.unc.edu Subject: Re: No bombers here. From: ajpierce@med.unc.edu (Andrew Pierce) Date: 1 Feb 92 19:29:19 GMT Message-ID: <1992Feb1.192919.20789@samba.oit.unc.edu> NOTE: I am posting this for Scott Adkins. He mailed to me directly instead of following up to the net. Here is the article he meant to post: From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) In article <1992Jan31.211040.21949@samba.oit.unc.edu> you write: > > Conversely, >for the experimental hill, where the spl bomb is no more effective than a >dat bomb, it seems that all progs would be of the mice type variety, >trying to replicate themselves as quickly as possible so that they could >never be completely destroyed. I am not sure that I completely agree with this. SPL bombs are still more useful than a DAT, but much much less effective. I think the worst kind of program to have is the mice-type program. The more spl's that you have in your program (assuming that the spl's are the core of your program trying to kill or hurt the enemy program), the less effective your program will be. Mice in particular will be very vulnerable to attack just because it is real slow after a short time. DAT and JMP bombing programs would be more effective since they would split much less and never truly slow down as much as what mice-like programs would. Good examples of this are the QUARTER mutations, where only 4 or 6 copies of dwarf programs are spawned and that is it. Other programs will lose against them if they split more than what QUARTER did in the fight. After seeing the performance of the SPL command in the X-Koth, I have been strongly swayed to the "AGAINST" side of changing the SPL command. I am of the strong opinion that you do not have to win just by slowing the enemy down with the SPL 0 bomb, and I think I have found some very good ways to protect myself against such weapons. Over a period of time, I think anybody can write a good program, and learn to combat the SPL bombs. I agree with Andy, that if the SPL bomb is going to be changed, it should not be reduced to the power of a simple DAT statement. That, to me, would destroy the very essence of Core War programming that I have enjoyed for so long... Scott Adkins sadkins@bigbird.cs.ohiou.edu Subject: Re: No bombers here. From: pausv@sssab.se (Paul Svensson) Date: 2 Feb 92 15:42:55 GMT Message-ID: <1992Feb2.154255.12368@herkules.sssab.se> >Wrong. The #1 program on the standard hill, "Sleepless 1.2", is in fact >very long and the entire piece of code is executed frequently. >Yes but how does it score against the spl bombing type programs?... >In a recent post on r.g.cw, Bill Shubert mentions your program as being >large, yet successful. Would you enlighten us readers of r.g.cw by >posting the source for Sleepless 1.2, so we all regain faith in ICWS'88? ============================================================================ Well... I'll give y'all a little more time to knock Sleepless 1.2 off the hill before posting the source (and sending in 1.3). A little more information to help you along: It is a variation of "sit in one place and bomb the hell out of memory". It's BIG, FAST, and STUPID, and does not really refute the fact that fancy programs tend to not do well. It does not copy any code anywhere. It does not look at the core, it just bombs DAT. It does not stop bombing when it's reached around to itself. It's two strengths are: It's FAST (bombs more than 1/2 of the core at light speed). It's NOT rendered useless after a single hit by a SPL bomb. As the name suggests, it was concocted one night when usenet was boring and IRC slow. Not having anywhere other than the hill to run my redcode, I haven't analyzed it very well. It's not very different from 1.0 and 1.1, but the first two were not even close to getting on the hill. Don't ask me why. This is how Sleepless 1.2 does against itself: The number of ties seems large for a program so singlemindedly offensive, I can't really explain that... >Program "Sleepless 1.2" (length 100) by "Paul Svensson " >(contact address "Odysseus.SSSab.SE!pausv@sssab.se"): >;strategy 1.0: bomb core and eat cycles >;strategy 1.1: diversified >;strategy 1.2: more bomb, less jumping around >Sleepless 1.2 wins: 13 >Ties: 14 And this is how it does agains everyone else; I've sorted it so that the ones doing best against Sleepless 1.2 come first. The break even point is at SmallDat D, the three before it beats it, while all below that point more or less loose. SplitBomb is the only one who can be said to "massacre" it. It hasn't fought Sargent, but if Kevin could send it in again, we'll see... >Program "SplitBomb" (length 12) by "Scott Adkins" >(contact address "sadkins@bigbird.cs.ohiou.edu"): >;strategy Slows the opponent down, and then unleashes a single deadly dwarf >;strategy to finish the job nicely. Uses "spl -1" similar to XTC, but in a >;strategy more efficient way, and much, much faster. Does well against many >;strategy splitters and bombers, but does poorly against mice and leech. >Sleepless 1.2 wins: 3 >SplitBomb wins: 37 >Ties: 0 >Program "Snow White and the Seven Dwarfs 1.2" (length 100) by "Paul Svensson " >(contact address "Odysseus.SSSab.SE!pausv@sssab.se"): >;strategy 1.0: 7 dwarfs, one target >;strategy 1.1: bigger dwarfs, and some imps too >;strategy 1.2: sacrifice thoroughness to gain speed >Sleepless 1.2 wins: 10 >Snow White and the Seven Dwarfs 1.2 wins: 17 >Ties: 13 >Program "CAKE B" (length 90) by "S. Halvorsen" >(contact address "snh@flipper.pvv.unit.no"): >;Strategy Cripple And Kill (the) Enemy. >;Strategy >;Strategy This program drops a lot of JMP 0 bombs, and when >;Strategy the enemy execute it, he gets stuck. >;Strategy After he is stuck, I have all the time i need to >;Strategy kill him off. >;Strategy >;Strategy Version B is better against scanners. >;Strategy (Only a few B-fields are non-zero.) >Sleepless 1.2 wins: 15 >CAKE B wins: 21 >Ties: 4 >Program "SmallDat D" (length 100) by "Tor Egge" >(contact address "tegge@pvv.unit.no"): >;strategy Use SPL/JMP to hit mod 4 and mod 5 hiders. >Sleepless 1.2 wins: 20 >SmallDat D wins: 20 >Ties: 0 >Program "Leech 1.2" (length 47) by "William Shubert" >(contact address "wms"): >;strategy Throw around "jmp" instructions. When the enemy executes one of >;strategy these instructions, they jump to a piece of code that forces them >;strategy to fork of tons more processes and clear the core. The last bit >;strategy of core a captured process clears will be itself, dying and giving >;strategy the Leech the win. >;strategy 1.2 mod: Move the trap routine far away from my code to make it >;strategy harder for leech-killer to find me. >;strategy For a full listing, just send a letter to wms@iwarp.intel.com >Sleepless 1.2 wins: 25 >Leech 1.2 wins: 15 >Ties: 0 >Program "TheRat" (length 10) by "William Shubert (& Arne H. Juul)" >(contact address "arnej@lise.unit.no"): >;strategy Bomb mod-4 locations with JMPs leading to a splitting & >;strategy bombing routine, hopefully making the enemy do the work. >;strategy Modified from wms' Leech 1.1, with a false clue to survive >;strategy my own antileech routine. Note the small size, I've worked >;strategy on it! >Sleepless 1.2 wins: 29 >TheRat wins: 10 >Ties: 1 >Program "Trinity Zwo" (length 7) by "Stefan Strack" >(contact address "stst@vuse.vanderbilt.edu"): >;strategy 1) Decrements B-operands at large intervals >;strategy 2) Cleans up debris with imp >;strategy 3) Finishes off with mod-2 bomber/imp-stomper >;strategy (Version 2.0: smaller, should tie less) >;strategy Submitted: Fri Jan 31 18:58:33 CST 1992 >Sleepless 1.2 wins: 27 >Trinity Zwo wins: 6 >Ties: 7 >Program "Walze" (length 98) by "Stefan Strack" >(contact address "stst@vuse.vanderbilt.edu"): >;strategy Submitted: Fri Jan 31 21:21:41 CST 1992 >Sleepless 1.2 wins: 26 >Walze wins: 3 >Ties: 11 >Program "Trinity Zwo.1" (length 99) by "Stefan Strack" >(contact address "stst@vuse.vanderbilt.edu"): >;strategy 1) Decrements B-operands at large intervals >;strategy 2) Cleans up debris with imp >;strategy 3) Finishes off with mod-2 bomber/imp-stomper >;strategy Version 2.0: smaller, should tie less >;strategy 2.1: moved imp away from body >;strategy Submitted: Fri Jan 31 21:07:44 CST 1992 >Sleepless 1.2 wins: 29 >Trinity Zwo.1 wins: 4 >Ties: 7 >Program "Cake Eater" (length 26) by "Tor Egge" >(contact address "tegge@pvv.unit.no"): >;strategy Bomb core with DAT. >Sleepless 1.2 wins: 25 >Cake Eater wins: 0 >Ties: 15 >Program "MUTAGEN /PAR" (length 4) by "Stefan Strack" >(contact address "stst@vuse.vanderbilt.edu"): >;strategy laces the core with crippling point-mutations and cleans up >;strategy the debris with systematic deletions (parallel version) >;strategy Submitted: Wed Jan 29 21:24:38 CST 1992 >Sleepless 1.2 wins: 35 >MUTAGEN /PAR wins: 5 >Ties: 0 >Program "Scanner 1.01" (length 98) by "Andy Pierce" >(contact address "ajpierce@med.unc.edu"): >;strategy Quickly kill the core. >;strategy (minor optimization) >Sleepless 1.2 wins: 33 >Scanner 1.01 wins: 2 >Ties: 5 >Program "Midget 1.4" (length 5) by "Paul Svensson " >(contact address "Odysseus.SSSab.SE!pausv@sssab.se"): >;strategy 1.0 stealthy prng dwarf >;strategy 1.1 better prime >;strategy 1.2 imp proofed >;strategy 1.3 bug fix >;strategy 1.4 bug fix >Sleepless 1.2 wins: 31 >Midget 1.4 wins: 0 >Ties: 9 -- Paul Svensson _ /| - Every absurdity needs a champion to defend it - SM5SJS \'o.0' Scandinavian System Support Fax: +46 13 115193 paul@sssab.se =(___)= Box 535 _ Phone: +46 13 111660 sunic!sssab!paul U SE-581 06 Linkoping, Sweden Home: +46 13 121021 Subject: KotH source with graphics From: wms@iwarp.intel.com (William Shubert) Date: Mon, 3 Feb 1992 00:08:28 GMT Message-ID: <1992Feb3.000828.3242@iWarp.intel.com> I have finally finished the first part of my X windows interface for King of the Hill corewar. If anybody wants it, just send me a mail request and I'll send you a shar file of the sources. It seems to work fine on my system with X11R5. I'm not sure if I used X11R5-specific stuff or not; I doubt it because I didn't do all that much. This does have switches to let you run on the experimental hill, ICWS '88, or a few other variants with differing core sizes, etc. As I add more features or corewar variants, I'll post notices and release newer versions. -Bill (wms@iwarp.intel.com) Subject: Re: No bombers here. From: kwhyte@dickson.uchicago.edu (Kevin Whyte) Date: 3 Feb 92 04:33:57 GMT Message-ID: <1992Feb3.043357.1259@midway.uchicago.edu> In article <1992Feb2.154255.12368@herkules.sssab.se> pausv@sssab.se (Paul Svensson) writes: >And this is how it does agains everyone else... I imagine it would massacre Sargent. Do you have the results against Kinch (a far improved Sargent)? For those who are curious, the idea Kinch was based on is: Search through memory for non-zero B fields. If you find one, bomb with jumps to a piece of code which first changes the search code to make it bomb all of core with dat 0's, and the splits like mad. The idea here is that once something actually jumps to the piece of code you have set up for it, it will quickly be so slow as to be useless ... thus just mop up, making sure not to miss anything. As far as I can tell, if it finds code you execute, you are dead. The reason it got pushed off the hill is that it was long enough that the best programs would find it before it found them. I am currently working on a more robust version, which should be at #1 any day now :). >Paul Svensson _ /| - Every absurdity needs a champion to defend it - >SM5SJS \'o.0' Scandinavian System Support Fax: +46 13 115193 >paul@sssab.se =(___)= Box 535 _ Phone: +46 13 111660 >sunic!sssab!paul U SE-581 06 Linkoping, Sweden Home: +46 13 121021 Kevin Subject: MUTAGEN /PAR From: stst@vuse.vanderbilt.edu (Stefan Strack) Date: 3 Feb 92 07:30:17 GMT Message-ID: <1992Feb3.073017.29502@vuse.vanderbilt.edu> Here's MUTAGEN /PAR, which was tied for first place a week ago on the standard hill for a few hours, but got quickly pushed to the lower ranks. It's a single-process bomber that also creates some confusion by decrementing two core-addresses per loop at long interval. It does fairly well against larger bombers, vampires and XTC-style scanners. ;redcode ;name MUTAGEN /PAR ;author Stefan Strack (stst@vuse.vanderbilt.edu) ;strategy laces the core with crippling point-mutations and cleans up ;strategy the debris with systematic deletions (parallel version) dist equ 422 start mov This is Walze (german for {steam}roller), last I checked somewhere in the middle of both the standard and the -x hill. Walze is simply an imp and a mod-2 bomber that doubles as an imp-stomper. The imp is separated by a large DAT #0 stretch to avoid triggering JMZ-scans. Primitive, but surprisingly effective. ;redcode ;name Walze ;author Stefan Strack (stst@vuse.vanderbilt.edu) ;strategy Submitted: @date@ impstop EQU start-14 bomb EQU impstop+1 start SPL imp SPL bomber bomber MOV bomb, The last installment, Trinity Zwo, is a hybrid between MUTAGEN /PAR and Walze. It starts off launching a long-interval B-field decrementer, a mod-2 bomber, and an imp. As the imp gets about half-way thru the core, the decrementing process falls thru and joins the mod-2 bomber/imp-stomper to catch even single-process opponents subverted by the imp. Trinity Zwo never made it above rank 7 on the standard hill and is currently somewhere in the lower half of the -x hill. ;redcode ;name Trinity Zwo ;author Stefan Strack (stst@vuse.vanderbilt.edu) ;strategy 1) Decrements B-operands at large intervals ;strategy 2) Cleans up debris with imp ;strategy 3) Finishes off with mod-2 bomber/imp-stomper ;strategy (Version 2.0: smaller, should tie less) ;strategy Submitted: @date@ DIST EQU 212 impstop EQU trinity-12 bomb EQU trinity-8 trinity SPL bomber SPL imp mutagen ADD #DIST, decrem decrem DJN mutagen, I got an amazing ammount of help (9 replies) when I put my program on here and asked if anyone could tell me what was wrong so instead of e-mailing those people individually (simply havent the time) I'd like to say a big THANX to all of you.Unfortunately having tryed all combinations of all the hints & tips it still doesnt work so I have a sneaking suspicion that the assembler is duff.Oh well. I have 2 questions (unrelated to the above) about corewars in general 1.Does an END statement take up an address in the core or does the assembler discard it? 2.What is the point in having DAT statements? Surely just a value at position X in memory is all thats required. eg instead of - DAT #3 MOV -1 @-1 ADD #1 -2 JMP -2 just have - 3 MOV -1 @-1 ADD #1 -2 etc.... Neil Robertson LUT Leicestershire England Subject: KotH weekly update From: wms@iwarp.intel.com (William Shubert) Date: Mon, 3 Feb 1992 17:40:23 GMT Message-ID: <1992Feb3.174023.15313@iWarp.intel.com> Well, it's Monday again. Here's the current hill: W/ L/ T Name Score 232/190/ 18 SplitBomb 714 215/161/ 64 Snow White and the Seven Dwarfs 1.2 709 203/139/ 98 CAKE B 707 209/194/ 37 Leech 1.2 664 205/197/ 38 Copy 1.4 653 194/190/ 56 SmallDat D 638 193/191/ 56 Sleepless 1.2 635 180/193/ 67 Walze 607 193/234/ 13 Scanner 1.21 592 194/236/ 10 Scanner 1.2 592 As you can see, Sleepless 1.2 has been dropping down the list and Splitbomb has gained the #1 position. Here's the ";strategy" for splitbomb: ;strategy Slows the opponent down, and then unleashes a single deadly dwarf ;strategy to finish the job nicely. Uses "spl -1" similar to XTC, but in a ;strategy more efficient way, and much, much faster. Does well against many ;strategy splitters and bombers, but does poorly against mice and leech. And for the experimental hill: W/ L/ T Name Score 215/104/121 CLONER II 766 237/172/ 31 QUARTER8 742 203/185/ 52 Schizo parasite-x 661 194/176/ 70 csapda 652 199/212/ 29 Cat's Paw 626 185/189/ 66 Walze 621 174/170/ 96 Trinity Zwo 618 183/195/ 62 Leech 2.0 611 138/108/194 ramscoop-x 608 182/197/ 61 Cat Paws B 607 I'm not sure as to whether I posted the strategy for Cloner II before; in any case, here it is: ;strategy quickly copies itself to a new location, splits, and then ;strategy searches for a new location to copy itself. Well, that's the hill for now! For entry instructions or the KotH source code, send mail to me. -Bill (wms@iwarp.intel.com) Subject: EBS Valentine Tournament From: DURHAM@ricevm1.rice.edu (Mark A. Durham) Date: Mon, 3 Feb 1992 18:10:55 GMT Message-ID: <16782AB4F.DURHAM@ricevm1.rice.edu> I received six votes total with respect to double-elimination versus round robin. The final tally is DE 4, RR 2. Thus the tournament will be double-elimination. Deadline for entry is February 14th. Send one Redcode program to me at durham@ricevm1.rice.edu by that date to enter. Because a DE tournament requires more active participation by the entrants, I will be working hard to accomodate any scheduling conflicts (Spring Break, etc.). Let me know of conflicts ASAP so I can inform your opponent. Mark A. Durham MAD Subject: Re: No bombers here. From: pausv@sssab.se (Paul Svensson) Date: 3 Feb 92 21:45:25 GMT Message-ID: <1992Feb3.214525.24773@herkules.sssab.se> In posting <1992Feb2.154255.12368@herkules.sssab.se> Paul Svensson writes: >I'll give y'all a little more time to knock Sleepless 1.2 off the hill >before posting the source (and sending in 1.3). >A little more information to help you along: Okay, you deserverd it :) Sargent beat Sleepless 40 to 0, and knocked it off the hill. target DAT #0, #0 bomb DAT #0, #0 ; sleepless MOV bomb, Date: Mon, 3 Feb 1992 23:13:00 GMT Last Update: February 3, 1992 TABLE OF CONTENTS ----------------- 1. What is Core War? 2. Is it Core War or Core Wars? 3. Where can I find more information about Core War? 4. What is the ICWS? 5. What is TCWN? 6. How do I join? 7. Are back issues of TCWNs available? 8. What is the EBS? 9. Where is the Core War archive? 10. Where can I find a Core War system for . . . ? 11. When is the next tournament? 12. What is KOTH? How do I enter? 13. What is Core War notation? 14. Other questions? --------------------------------------------------------------------- Q1: What is Core War? A1: Core War is a game played by two or more programs (and vicariously by their authors) written in an assembly language called Redcode and run in a virtual computer called MARS (for Memory Array Redcode Simulator). The object of the game is to cause all of the opposing programs to terminate, leaving your program in sole possesion of the machine. There are Core War systems available for most computer platforms. Redcode has been standardized by the ICWS, and is therefore transportable between all standard Core War systems. ---------------------------------------------------------------------- Q2: Is it "Core War" or "Core Wars"? A2: Both terms are used. Early references were to Core War. Later references seem to use Core Wars. I prefer "Core War" to refer to the game in general, "core wars" to refer to more than one specific battle. ---------------------------------------------------------------------- Q3: Where can I find more information about Core War? A3: Core War was first described in the "Core War Guidelines" of March, 1984 by D. G. Jones and A. K. Dewdney of the Department of Computer Science at The University of Western Ontario (Canada). Dewdney wrote several "Computer Recreations" articles in "Scientific American" which discussed Core War, starting with the May 1984 article. Those articles are contained in an anthology: Author: Dewdney, A. K. Title: The Armchair Universe: An Exploration of Computer Worlds Published: New York: W. H. Freeman (c) 1988 Library of Congress Call Number: QA76.6 .D517 1988 --------------------------------------------------------------------- Q4: What is the ICWS? A4: About one year after Core War first appeared in Sci-Am, the "International Core War Society" (ICWS) was established. Since that time, the ICWS has been responsible for the creation and maintenance of Core War standards and the running of Core War tournaments. There have been six annual tournaments and two standards (ICWS'86 and ICWS'88). The ICWS is currently in a state of flux, but should stabilize soon. --------------------------------------------------------------------- Q5: What is TCWN? A5: Since March of 1987, "The Core War Newsletter" (TCWN) has been the official newsletter of the ICWS. It is supposed to be published quarterly, but has appeared sporadically instead. This should change soon as TCWN is changing publishers. In fact, it may be available through this newsgroup in the near future. --------------------------------------------------------------------- Q6: How do I join? A6: For more information about joining the ICWS and/or subscribing to TCWN, contact: Jon Newman One Microsoft Way Redmond, WA 98052-6399 EMail: jonn@microsoft.com If you wish to contribute an article, cartoon, letter, joke, rumor, etc. to TCWN, please send it to me at Mark A. Durham P.O. Box 301173 Houston, TX 77230-1173 EMail: durham@ricevm1.rice.edu and clearly indicate its destination. The ICWS and TCWN are in a transitional period (as of February 1992). Please be patient with them. ---------------------------------------------------------------------- Q7: Are back issues of TCWN available? A7: Arrangements are being made to make TCWN back issues available. This will probably involve a $4.00(US) fee to be sent to the Copyright Clearance Center as well as an additional postage and handling charge. Check out the synopses posted previously. --------------------------------------------------------------------- Q8: What is the EBS? A8: The Electronic Branch Section (EBS) of the ICWS is a group of Core War enthusiasts with access to electronic mail. There are no fees associated with being a member of the EBS, and members do reap some of the benefits of full ICWS membership without the expense. For instance, the ten best warriors submitted to the EBS tournament will be entered into the annual ICWS tournament. Now that rec.games.corewar has been created, the EBS will move most of its business to the newsgroup. The current goal of the EBS is to be at the forefront of Core War by writing and implementing new standards and test suites in preparation for the tenth anniversary of Core War in May of 1994. Its immediate business will be to set up a Charter and establish its officers. ---------------------------------------------------------------------- A9: Where is the Core War archive? Q9: Many documents such as the guidelines and the ICWS standards along with previous tournament Redcode entries and complete Core War systems are available via anonymous ftp from soda.berkeley.edu (128.32.131.179) in the pub/corewar directories. ---------------------------------------------------------------------- Q10: Where can I find a Core War system for . . . ? A10: First, check out the Core War systems available via anonymous ftp from soda.berkeley.edu. Currently, there are X-Window, IBM PC-compatible, Macintosh, and Amiga Core War systems available there. Others may appear. The following suppliers have ICWS'88 compatible systems for IBM PC compatibles: The Core War Colosseum AMRAN 5712 Kern Drive Huntington Beach, CA 92649-4535 Price: $39.95 CoreMaster(TM) THINK Software 524 Paige Drive Birmingham, AL 35226 (205)979-9475 Price: $34.95 + $3.00 S&H Apple Macintosh computers: Core! Jon Newman One Microsoft Way Redmond, WA 98052-6399 EMail: jonn@microsoft.com (Note: Core! is NOT a Microsoft product.) Price: $14.00 registration fee, plus $3.00 S&H. S&H fee waived if you send 800k disk and stamped, self-addressed envelope. Also available from sumex-aim.stanford.edu and listserv@ricevm1.rice.edu and soda.berkeley.edu. Commodore Amiga computers: The MADgic Core c/o Mark A. Durham P.O. Box 301173 Houston, TX 77230-1173 EMail: durham@ricevm1.rice.edu A version of The MADgic Core is available from soda.berkeley.edu. CoreWars (German language version) UNICORN systems Bernstrasse 67 CH-4852 Rothrist Switzerland Price: sFr 45.-- Commodore 64/128 computers: Barry Cohen 65 West 90th Street, #23E New York, NY 10024 Price: Not Available My apologies to those of you who have Core War systems which are not listed here or are incorrectly listed here. Please send me information about the systems (base system, ICWS standards compatibility, extensions, price, etc.) and I will be sure to include it in next month's MAD FAQs. CAUTION! There are many, many Core War systems available which are NOT ICWS'88 (or even ICWS'86) compatible available at various archive sites. Reviews of Core War systems would be greatly appreciated in the newsgroup and in the newsletter. Please post or EMail to me any review of any Core War system you have tried out so that others may learn from your experience. ---------------------------------------------------------------------- Q11: When is the next tournament? A11: The EBS will be having a tournament February 14th. It will be a double-elimination tournament under ICWS'88 rules with a core size of 8192, maximum program size of 64 instructions, maximum task limit of 64 tasks, and maimum of 100 000 cycles before declaring a draw. Scoring will be 3 points per win, 1 point per tie, and no points for a loss. Entrants will receive their previous opponent's and upcoming opponent's source code each round and will be given an opportunity to change warriors. ---------------------------------------------------------------------- Q12: What is KOTH? How do I enter? A12: King Of The Hill (KOTH) is an ongoing Core War tournament available to anyone with EMail provided by William Shubert . You enter by submitting a Redcode program with special comment lines via EMail. You will receive a reply indicating how well your program did against the current top ten programs "on the hill". If your program finished in the top ten, it will remain on the hill until such time as it finishes eleventh against another challenger, at which time it "falls off" the hill. Entry rules for King of the Hill Corewar: 1) Write a corewar program. KotH is fully ICWS '88 compatible, EXCEPT that a comma (",") is required between two arguments. 2) Put the line ";redcode" at the top of your program. This MUST be the first line. Anything before it will be lost. If you wish to receive mail on every new entrant, use ";redcode verbose". Otherwise you will only receive mail if a challenger makes it onto the hill. Use ";redcode quiet" if you wish to receive mail only when you get shoved off the hill. Additionally, adding ";name " and ";author " will be helpful in the performance reports. Do NOT have a line beginning with ";address" in your code; this will confuse the mail demon and you won't get mail back. In addition, it would be nice if you have lines beginning with ";strategy" that describe the algorithm you use. 3) Mail this file to "wms@iwarp.intel.com". 4) Within a few minutes you should get mail back telling you whether your program compiled correctly or not. If it did compile correctly, sit back and wait; if not, make the change required and re-submit. 5) In an hour or so you should get more mail telling you how your program performed against the current top 10 programs. If no news arrives in an hour, don't worry; entries are put in a queue and run through the tournament one at a time. A backlog may develop. Be patient. MORE ON KOTH COREWAR IMPLEMENTATION Core size: 8,000 instructions Max processes: 8,000 per program Duration: After 80,000 cycles per program a tie is declared. Example program: ;redcode ;name Dwarf ;author A. K. Dewdney bomb dat #0 dwarf add #4,bomb mov bomb,@bomb jmp dwarf end dwarf If you want, enter your program with ";redcode-x" and PRESTO! YOU'RE IN THE EXPERIMENTAL TOURNAMENT! Now what does this mean? 1> When a process splits, it's children share it's CPU time. 2> When a process dies, it's CPU time is given to it's sibling, or it's siblings descendants if the sibling has split. 3> ALL ADDRESSING MODES ARE ALLOWED. So "add #4, #5" will become "add #4, #9" after execution. ---------------------------------------------------------------------- Q13: What is Core War notation? A13: There are some important notational conventions which should be followed when writing about Core War. Before we discuss them, you need to understand Redcode syntax. Redcode consists of assembly language instructions of the form