From: bdthomse@peruvian.cs.utah.edu (Brant Thomsen) Subject: The '94 Warrior Date: 1 Nov 1994 05:56:52 GMT Message-ID: <394lb4$ko4@magus.cs.utah.edu> __ __| | ) _ \ | | \ \ / _) | __ \ _ \ / ( | | | \ \ \ / _` | __| __| | _ \ __| | | | | __/ \__ |___ __| \ \ \ / ( | | | | ( | | _| _| |_|\___| _/ _| \_/\_/ \__,_|_| _| _|\___/ _| October 31, 1994 Issue #13 ______________________________________________________________________________ _The_'94_Warrior_ is a monthly newsletter dedicated to supporting and encouraging the game of Corewars. This includes coverage of the more popular "hills" (which allow users anywhere on the Internet to compete against other users), and also by encouraging traffic in the rec.games.corewar newsgroup. The FAQ (Frequently Asked Questions) for the rec.games.corewar newsgroup is available through anonymous FTP to rtfm.mit.edu, as /pub/usenet/news.answers/games/corewar-faq.Z. There are also several tutorials on the '88 and '94 (draft) standard available on scotch.csua.berkeley.edu (128.32.43.51) that will greatly ease the process of becoming a proficient "redcoder." I would highly recommend referring to the FAQ if you are curious about exactly what Corewars is, or if you are unfamiliar with any of the terms used in this newsletter. ______________________________________________________________________________ CHANGES and CORRECTIONS: There are several changes that have occurred in the last two months. Please remind me of any that I may have missed, and I'll be sure to get them in the next issue of _The_'94_Warrior_. As you may have noticed above, the staff here at _The_'94_Warrior_ has been working diligently to print the correct Corewar Archive site. The correct address is now "scotch" instead of "soda". Accessing "ftp.csua.berkeley.edu" should still work as well. The fall TCWN newsletter is now available on scotch as pub/corewar/documents/tcwn0994.z. I'd like to highly recommend it, but since I don't have a PostScript printer, I'm afraid I can't. (Where is a copy of "GhostScript" when I need it?!) However, if this issue is anything like the previous ones, I can promise that you are in for a real treat. Kudos to Mark Durham once again! For those of you that like an occasional break from writing redcode, a C++ Robots Server is now up and running. Send mail with the subject "help summary c++robots" (without the quotes) to pbmserv@netcom.com for more information, and be sure to watch the newsgroup for more posts by Richard Rognlie about this exciting event. Another exciting thing to watch the newsgroup for is Paul Kline's status listings on the "hot" hills. For those that keep having their warriors kicked off the hills (such as myself), this will be a nice way to find out what is currently happening. Perhaps it will also cut down the number of times that infamous "Just Looking" warrior gets sent to the hill! On Stormking, the hills have been enhanced. Now, when you are notified about a warrior on one of those hills, the subject line will tell you who it is you are going to be reading about. Several more enhancements are expected to follow as well, so be sure to watch the newsgroup for more information. The August and September archives for the rec.games.corewar newsgroup have also been uploaded to scotch. Look in the "incoming" directory. ______________________________________________________________________________ The ICWS '94 Draft Hill: Standard: '94 Draft (with extensions) Core size: 8000 instructions Max processes: 8000 per program Duration: After 80,000 cycles, a tie is declared. Max entry length: 100 instructions The current ICWS '94 Draft hill on "Pizza": # %W/ %L/ %T Name Author Score Age 1 46/ 37/ 17 HeremScimitar A.Ivner,P.Kline 156 27 2 43/ 31/ 25 Torch t15 P.Kline 155 7 3 36/ 24/ 40 Blue Funk 3 Steven Morrell 149 208 4 38/ 30/ 32 Rude Wind P.Kline 147 57 5 31/ 15/ 54 B-Panama X Steven Morrell 147 149 6 45/ 44/ 11 Agony II Stefan Strack 147 143 7 33/ 23/ 45 Blue Funk Steven Morrell 143 520 8 31/ 20/ 48 Silk Warrior 1.4 J.Pohjalainen 142 150 9 35/ 31/ 34 Killer Instinct II Anders Ivner 140 2 10 39/ 38/ 23 Leprechaun II Anders Ivner 139 1 11 39/ 40/ 21 SJ-4 J.Layland 139 209 12 41/ 44/ 15 Iron Gate 1.5 Wayne Sheppard 138 497 13 37/ 37/ 26 Stimpy v2.0 Brant D. Thomsen 138 42 14 29/ 21/ 50 Phoenix 1.2 J.Pohjalainen 137 100 15 28/ 22/ 51 Aeka T.Hsu 134 163 16 31/ 29/ 40 Sasami T.Hsu 133 233 17 38/ 44/ 17 Test Wayne Sheppard 133 6 18 27/ 23/ 50 Bremstone 2.X M R Bremer 132 112 19 27/ 22/ 51 Cannonade P.Kline 132 378 20 37/ 43/ 20 The Spanish Inquisition Steven Morrell 132 36 The big leaders on the hill are Torch and HeremScimitar. Scimitar (by Paul Kline) used some interesting tricks to take the hill by storm when it was introduced a couple of weeks ago. Last tile I examined the hill, replicators were the dominant force. Now it appears that stones/bombers have the top positions. Of course, the hill is 115 battles older, so quite a bit has happened since then. Congratulations are also due for Steven Morrell, as his first Blue Funk warrior passes the 500 age mark. ______________________________________________________________________________ The ICWS '94 Draft Experimental Hill: Standard: '94 Draft (with extensions) Core size: 55,440 instructions Max processes: 10,000 per program Duration: After 500,000 cycles, a tie is declared. Max entry length: 200 instructions The current ICWS '94 Experimental (Big) hill on "Pizza": # %W/ %L/ %T Name Author Score Age 1 46/ 32/ 22 ivscan6b J.Layland 161 35 2 47/ 36/ 17 Genocide 94x Mike Nonemacher 158 1 3 34/ 16/ 50 Big Phoenix 1.0 J.Pohjalainen 152 6 4 34/ 18/ 48 Aleph 1 Jay Han 150 33 5 44/ 38/ 19 Request-55440 Brant D. Thomsen 149 171 6 42/ 36/ 22 Stimpy v2.0 Brant D. Thomsen 148 26 7 46/ 44/ 10 Test Stefan Strack 147 7 8 43/ 41/ 16 Pyramid v5.3 Michael Constant 145 62 9 44/ 45/ 11 Rave B4.1 Stefan Strack 144 132 10 30/ 16/ 54 Big Silk Warrior 1.0 J.Pohjalainen 143 13 11 34/ 25/ 41 Variation G-1 Jay Han 142 135 12 38/ 39/ 23 Vanity IIx Stefan Strack 137 126 13 39/ 42/ 19 Fscan Jay Han 136 19 14 38/ 41/ 21 Aleph 0 Jay Han 136 34 15 30/ 27/ 43 Splash 1 Jay Han 133 136 16 29/ 26/ 45 Blue Funk Steven Morrell 133 25 17 29/ 25/ 47 NotSoBigImps James Layland 132 31 18 40/ 49/ 11 Squint Mike Nonemacher 131 109 19 31/ 31/ 38 Lucky 13 Stefan Strack 131 177 20 29/ 27/ 44 Der Zweite Blitzkrieg - 9 Mike Nonemacher 131 133 Although ivsan6b is still on top of the hill, it now has some new competition. Genocide and Big Phoenix are two new warriors that have jumped right onto the hill. Genocide is a F-scanner, and Big Phoenix is almost a paper. ______________________________________________________________________________ The ICWS '88 Standard Hill: Standard: '88 Core size: 8000 instructions Max processes: 8000 per program Duration: After 80,000 cycles, a tie is declared. Max entry length: 100 instructions The current Standard KotH hill on "Pizza": # %W/ %L/ %T Name Author Score Age 1 43/ 28/ 29 Yop La Boum v2.1 P.E.M & E.C. 158 55 2 33/ 22/ 45 Sphinx v5.1 W. Mintardjo 145 11 3 33/ 23/ 44 Der Zweite Blitzkrieg Mike Nonemacher 144 59 4 44/ 43/ 13 Dragon Spear c w blue 144 77 5 31/ 20/ 49 CAPS KEY IS STUCK AGAIN Steven Morrell 142 65 6 29/ 15/ 56 ttti nandor sieben 142 81 7 31/ 20/ 49 The Plauge Anonymous 141 14 8 40/ 40/ 19 Vanity II Stefan Strack 141 99 9 43/ 45/ 12 Iron Gate 1.5 Wayne Sheppard 141 108 10 30/ 20/ 49 NC Killer Anonymous 140 15 11 39/ 40/ 21 Request v2.0 Brant D. Thomsen 139 78 12 29/ 20/ 51 Night Crawler Wayne Sheppard 139 4 13 29/ 19/ 52 Blue Funk 88 Steven Morrell 138 24 14 38/ 39/ 22 Christopher Steven Morrell 138 51 15 31/ 25/ 44 B-Panama V.i Steven Morrell 136 9 16 35/ 35/ 30 Annihilator v2.1 Carlos Paredes 136 2 17 36/ 37/ 27 Keystone t21 P.Kline 135 97 18 27/ 20/ 53 Imprimis 6 Anonymous 134 16 19 37/ 41/ 22 Titled Steven Morrell 132 1 20 37/ 44/ 19 SJ-4a J.Layland 129 58 The '88 hill hasn't aged much (10), but don't let that fool you. This hill is still very busy. I really enjoy watching as warriors try to make the transition from the beginner hill to the standard hill. Good luck! ______________________________________________________________________________ The ICWS '94 Beginner Hill: Standard: '94 Draft (with extensions) Core size: 8000 instructions Max processes: 8000 per program Duration: After 80,000 cycles, a tie is declared. Max entry length: 100 instructions The current Beginner KotH hill on "Pizza": # %W/ %L/ %T Name Author Score Age 1 56/ 34/ 10 Samba2.2 Mr. Jones 179 13 2 54/ 35/ 11 Viewmaster4.0 Ryan Case 172 214 3 53/ 40/ 7 Ecstacy (XTC) Brant Thomsen 166 81 4 34/ 10/ 55 Rabid Dwarfs v1.3 Brian Zellner 158 56 5 42/ 27/ 31 Ox v1.0 Brian Zellner 158 10 6 40/ 36/ 24 Bloody Fang v2.1 Bharat Mediratta 145 1 7 36/ 34/ 31 Green Knight v1.7 Brian Zellner 137 57 8 30/ 24/ 46 Slate, v0.3a Bharat Mediratta 136 135 9 25/ 17/ 58 Paperous Mr. Jones 133 6 10 31/ 31/ 38 Count Zero #1 Marc Schefer 131 77 11 27/ 23/ 50 Rubarbe et mort-vivant J.P.Laurin 130 84 12 27/ 24/ 48 War Machine v2.65 Matthias Wollnik 130 2 13 27/ 24/ 49 War Machine v2.6 Matthias Wollnik 129 3 14 37/ 52/ 11 Cat v2.0 Tim Scheer 122 155 15 24/ 27/ 49 War Machine v2.5 Matthias Wollnik 121 4 16 35/ 53/ 12 It Hari 117 198 17 21/ 25/ 54 Mostly Harmless Frank J. T. Wojcik 117 45 18 21/ 31/ 47 The Foo Bar and Grill James Jesensky 111 7 19 27/ 45/ 29 Rubarbe et grafigne J.P.Laurin 109 83 20 33/ 62/ 5 Stepper v1.0 Gollum 104 37 Although I haven't been keeping an accurate count, I can promise that this is the busiest of the four hills that I watch. Many of the warriors submitted don't make it, but there certainly are many attempts. ______________________________________________________________________________ HINTS and HELPS: As I have been without a (home) computer for the last couple of months, I'm afraid I haven't had the time to put together a hint without delaying this newsletter another week or so. Of course, next month's hint will be twice as good to make up for it! ______________________________________________________________________________ Looking to the Future: This newsletter is now (again) being published monthly. As always, your comments, suggestions, criticisms, and submissions are encouraged and appreciated. -- Brant D. Thomsen Man will occasionally stumble over the truth, (bdthomse@peruvian.cs.utah.edu) but most times he will pick himself up University of Utah and carry on. - Winston Churchill From: hbecker@zeus.rbi.informatik.uni-frankfurt.de (Helmar Becker) Subject: PCRobots Date: 1 Nov 1994 11:10:35 GMT Message-ID: <3957nb$cjh@zeus.rbi.informatik.uni-frankfurt.de> Hello All! Are there competitions for PCRobots? FTP sites? WWW Pages? Thanks in advance, Helmar From: rrognlie@netcom.com (Richard Rognlie) Subject: Re: C++Robots questions Message-ID: Date: Tue, 1 Nov 1994 12:47:06 GMT Andre van Dalen (andre@targon.UUCP) wrote: : Hello world, : I stil have a couple questions about C++ robots, based on exerience with : a likewise system I build 12 years ago. : - what is the origin of the room? Is the following correct? : 0,0 10000,0 : 10000,0 10000,10000 NO. It is: 10000,0 10000,10000 0,0 10000,0 : - how big is a robot? (in meters x,y) 1 meter round. However, robot-to-robot collisions have yet to be implemented. : - If my location is 100, 100 where is the robot size significant? : (100-size/2 - 100+size/2 or 100 - 100 + size?) 100-size/2 .. 100+size/2 : - If you hit a wall, do you stop immediatly and is the maximum penalty : for this 4 points? Yes and Yes. : - What is the relation between the internal time() and the seconds the : drive works with? (for timed movement) 100 CPU cycles (time units) = 1 second. : - What is the basis for the scheduling? opcodes or expressions? How many : expressions are executed each second? Each robot get 100 cycles. scan(), drive() and cannon() are interrupts and end your timeslice. This is 1 second. Your code is compiled to a SPARC .o file by GNU C++. 1 cycle = 1 opcode. : - on the current hill, robots are pitted against eachother, but this : is essentially who finds who first. Robots become much more intelligent : when they are put with 4 or 5 in the room and then fight. Then damage : control is of a higher importance. (maybe a second hill can be started?) A possibility... : Thanks for running this hill, it promises to be a lot of fun. : Andre van Dalen : -- : The mail| Andre van Dalen : demon...|uucp: andre@targon.uucp Tel: ++31 3473 65240 Siemens Nixdorf inf sys : hits!.@&| adalen.via@sni.de Fax: ++31 3473 65212 Mijlweg 7, 4131 PJ : --more--|nerv: adalen.via Vianen, The Netherlands -- /\/\/\ | Richard Rognlie / Sr. Computer Analyst / PRC Inc. / McLean, VA / \ \ \ | E-Mail: rrognlie@netcom.com *or* rognlie_richard@prc.com \ / / / | Phone: (Home) (703) 361-4764 (Office) (703) 556-2458 \/\/\/ | (Fax) (703) 556-1174 From: gl8f@fermi.clas.Virginia.EDU (Greg Lindahl) Subject: PBEM fanzine available Message-ID: Date: Wed, 2 Nov 1994 03:43:36 GMT The latest issue of PBEM, a free fanzine for free computer-moderated play-by-email games, was just posted to rec.games.pbm. This issue features articles on C++Robots and email Soccer simulations. Previous issues have covered games such as Corewars, VGA Planets, and space and fantasy games. If you'd like a copy, here's how to get one: Usenet: posted to rec.games.pbm () WWW: http://fermi.clas.virginia.edu/~gl8f/pbem_magazine.html FTP: ftp.erg.sri.com:/pub/pbm/magazines/pbem.9407.gz (gzipped format) Email: write me at gl8f@virginia.edu, and ask me for a copy. I'm looking for articles of all sorts for future issues. Write me if you're interested. From: wfp5p@tigger.itc.Virginia.EDU (Bill Pemberton) Subject: C++ Robots Shadow Message-ID: Date: Wed, 2 Nov 1994 16:02:50 GMT Since no one else has posted any robots, here's my robot Shadow. It did ok on the hill, but gets burned by robots that keep moving. // Shadow // Attempts to stay near a target #include "robots.h" main() { int x; int range; x = 0; drive(rand(360),50); while(1) { if(range=scan(x+=341,7)) { while(range) { x+=5-(scan(x-5,5) != 0)*10; x+=3-(scan(x-3,3) != 0)*6; if (range=scan(x,10)) { cannon(x,range); cannon(x,range); } if(range>400) drive(x,100); else drive(x,0); } x+=225; } } } -- Bill From: PK6811S@ACAD.DRAKE.EDU Subject: The current ICWS '94 Draft hill: Date: 2 Nov 1994 17:54:42 -0600 Message-ID: <01HJ0GTJS56A004WMZ@ACAD.DRAKE.EDU> /+|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+/ / * _________ . * . + . +__ __ * . * / /+ \========\ ____*_______ + ____* /==\* /==\_____ ._______+ ______ + / / . / \ .\/ /====\\===== \_/====\ \ \/\/ /\====\ \======\/=====/ / / \ \____( __ )| | \/\ ___/ + \ /. / __ \_| | \/\___ \ . / / * .\______ / \____/ |__|* \___ / . \__/\ / (____ /|__| /____ / / / . . + \/ + + . * \/ * .\/ + * \/ . + . \/ + / / * . . * . * . . * + / /|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-/ The current ICWS '94 Draft hill: # %W/ %L/ %T Name Author Score Age 1 43/ 32/ 25 Torch t15 P.Kline 154 8 2 45/ 38/ 17 HeremScimitar A.Ivner,P.Kline 152 28 3 32/ 14/ 54 B-Panama X Steven Morrell 150 150 4 38/ 30/ 32 Rude Wind P.Kline 147 58 5 35/ 23/ 42 Blue Funk 3 Steven Morrell 147 209 6 33/ 19/ 48 Silk Warrior 1.4 J.Pohjalainen 146 151 7 45/ 45/ 10 Agony II Stefan Strack 144 144 8 31/ 21/ 48 Phoenix 1.2 J.Pohjalainen 142 101 9 36/ 31/ 34 Killer Instinct II Anders Ivner 140 3 10 31/ 22/ 47 Blue Funk Steven Morrell 140 521 11 37/ 37/ 26 Stimpy v2.0 Brant D. Thomsen 136 43 12 38/ 40/ 22 Leprechaun II Anders Ivner 136 2 13 39/ 41/ 20 SJ-4 J.Layland 136 210 14 41/ 45/ 14 Iron Gate 1.5 Wayne Sheppard 136 498 15 32/ 28/ 40 Sasami T.Hsu 136 234 16 27/ 20/ 53 Aeka T.Hsu 134 164 17 37/ 41/ 23 JBR M R Bremer 133 1 18 27/ 22/ 51 Bremstone 2.X M R Bremer 133 113 19 27/ 21/ 52 Cannonade P.Kline 133 379 20 37/ 43/ 19 The Spanish Inquisition Steven Morrell 132 37 21 2/ 98/ 0 Status Check Anonymous 7 0 From: rrognlie@netcom.com (Richard Rognlie) Subject: Re: C++Robots parms. Change Them? Message-ID: Date: Wed, 2 Nov 1994 18:49:47 GMT James J Jesensky (jesensky@mix.cse.psu.edu) wrote: : 1. Is 5 matches really enough? I realize we don't need 100's as in Corewar : but maybe 10. : 2. There seems to be too many ties. (Note: unlike Corewar, ties in crobots : are rare) Perhaps the CPU limit should be increased. The main problem is time. During the day, it can take upwards of 10-15 minutes to process a single incoming robot. This is due to the loading of the Netcom machines. One step that was taken to lighten the load was to shorten the CPU limit from 6000 seconds (100 minutes of C++Robots time) to 1800 (30 minutes of C++Robots time). If we go to 10 matches, we still have the time constraint. At some point in the future, C++Robots may be moved to a machine with a lighter load and more horsepower, but who knows when that will occur (if ever). Perhaps a match should be changed to: first robot to N points... Like most sport teams do (when they're not on strike). Richard -- /\/\/\ | Richard Rognlie / Sr. Computer Analyst / PRC Inc. / McLean, VA / \ \ \ | E-Mail: rrognlie@netcom.com *or* rognlie_richard@prc.com \ / / / | Phone: (Home) (703) 361-4764 (Office) (703) 556-2458 \/\/\/ | (Fax) (703) 556-1174 From: jesensky@mix.cse.psu.edu (James J Jesensky) Subject: ARENA II: Questions!! Date: 3 Nov 1994 02:23:11 GMT Message-ID: <399hig$s2u@psuvax1.cse.psu.edu> 1. I assume you can submit turns several times a day? For example entering a store (turn 1) to see what is for sale. Buying items and researching a weapon tech. (turn 2). Go to arena if weapon tech. is learned (turn 3). 2. Do you have to specify attack commands (perhaps 10, one for each round)? It seems this part of the rules post was deleted by the time it reached my site. Thanks Jim From: jesensky@mix.cse.psu.edu (James J Jesensky) Subject: Re: ARENA II: Questions!! Date: 3 Nov 1994 02:35:31 GMT Message-ID: <399i9j$scv@psuvax1.cse.psu.edu> In article <399hig$s2u@psuvax1.cse.psu.edu> jesensky@mix.cse.psu.edu (James J Jesensky) writes: >1. I assume you can submit turns several times a day? For example [...] >Thanks >Jim Sorry...wrong news group *) From: jesensky@mix.cse.psu.edu (James J Jesensky) Subject: skeet.c Date: 3 Nov 1994 02:58:56 GMT Message-ID: <399jlg$ss1@psuvax1.cse.psu.edu> BEGIN //skeet.c //James Jesensky // //Horizontal movement/Vertical scanning #include "robots.h" main() { int s; if (loc_y()>5000) while(loc_y()>5000) drive(270,100); else while(loc_y()<5000) drive(90,100); drive(0,0); while(speed()); while(1) { while(1) { drive(0,100); if (loc_x()>9500) { drive(180,0); while(speed()>49); drive(180,100); break; } if (s=scan(90,10)) cannon(90,s); else if (s=scan(270,10)) cannon(270,s); } while (s=scan(180,10)) cannon(180,s); while(1) { drive(180,100); if (loc_x()<500) { drive(0,0); while(speed()>49); drive(0,100); break; } if (s=scan(90,10)) cannon(90,s); else if (s=scan(270,10)) cannon(270,s); } while (s=scan(0,10)) cannon(0,s); } } END From: jesensky@mix.cse.psu.edu (James J Jesensky) Subject: outland.c Date: 3 Nov 1994 02:58:00 GMT Message-ID: <399jjo$sri@psuvax1.cse.psu.edu> BEGIN //outland.c //James Jesensky // //Perimeter movement/orthangonal scanning #include "robots.h" main() { int s; while(1) { while(1) { drive(0,100); if (loc_x()>9500) { drive(0,0); while(speed()); break; } if (s=scan(90,10)) cannon(90,s); } while (s=scan(135,10)) cannon(135,s); while(1) { drive(90,100); if (loc_y()>9500) { drive(90,0); while(speed()); break; } if (s=scan(180,10)) cannon(180,s); } while (s=scan(215,10)) cannon(215,s); while(1) { drive(180,100); if (loc_x()<500) { drive(180,0); while(speed()); break; } if (s=scan(270,10)) cannon(270,s); } while (s=scan(315,10)) cannon(315,s); while(1) { drive(270,100); if (loc_y()<500) { drive(270,0); while(speed()); break; } if (s=scan(0,10)) cannon(0,s); } while (s=scan(45,10)) cannon(45,s); } } END From: jesensky@mix.cse.psu.edu (James J Jesensky) Subject: xjena.c Date: 3 Nov 1994 02:59:47 GMT Message-ID: <399jn3$ssn@psuvax1.cse.psu.edu> BEGIN //xjena.c //James Jesensky // //Bouncing ball algorithm with 4 way scanning #include "robots.h" main() { int d=45, r, x, y; while(1) { drive(d,100), x=loc_x(), y=loc_y(); if (x<1000 && d==135) d=45; else if (x<1000 && d!=45) d=315; else if (x>9000 && d==45) d=135; else if (x>9000 && d!=135) d=225; if (y<1000 && d==315) d=45; else if (y<1000 && d!=45) d=135; else if (y>9000 && d==45) d=315; else if (y>9000 && d!=315) d=225; if (r=scan(0,10)) cannon(0,r),cannon(10,r),cannon(350,r); else if (r=scan(90,10)) cannon(90,r),cannon(100,r),cannon(80,r); else if (r=scan(180,10)) cannon(180,r),cannon(190,r),cannon(170,r); else if (r=scan(270,10)) cannon(270,r),cannon(280,r),cannon(260,r); } } END From: ccoop@teleport.com (Christopher Cooper) Subject: Help, novice needs C++Robots Date: 3 Nov 1994 07:47:30 -0800 Message-ID: <39b0mi$o4p@elaine.teleport.com> Just signed on the Inet and would like to find a BBS or other location to download latest version of C++Robots. I have a copy of PCROBOTS and it looks like a nice interface. Seems like more people are playing C++Robots though. Used to play an Origin Systems game called OMEGA, where the player designed and programmed a cyber tank and then challenged the program's library of tanks. I finished em all off and then there was no one play with. I had an Amiga at the time, since have moved into 486 land. Any advice would be appreciated. -- ccoop@teleport.COM Public Access User --- Not affiliated with Teleport Public Access UNIX and Internet at (503) 220-1016 (2400-14400, N81) From: hanwen@blade.stack.urc.tue.nl (Han-Wen Nienhuys) Subject: CROBOTS source files? Date: 3 Nov 1994 14:40:55 GMT Message-ID: <39aspn$9sh@tuegate.tue.nl> A while ago I emailed with someone who was interested in CROBOTS source files. He told that he had found a collection of those at (I am not sure) Stanford. Does anybody know where I can find those robots? I need more opponents for testing my (I admit, not unsuccesful :) robots greetings, /HaWee/ {fido: 2:284/102.27,email: hanwen@stack.urc.tue.nl} From: riepenha@desy.de (Frank Riepenhausen) Subject: Re: C++Robots Unix test platform? Date: 3 Nov 1994 20:08:36 GMT Message-ID: <39bg04$9gg@dscomsa.desy.de> Jeff Simpson (jms4759@ssu037.ssu.umd.edu) wrote: : I have been trying toget started writing some robots, but would like : to compile and test them here at my university. We have Ultrix running on a : DEC 5000 and would like to find some way to test my progs before sending : them to battle. Well, I have written a C-Simulator to do just that. If You mail me I could send You a copy. It is far from perfect though. Due to a number of bugs in the C++Server and in my simulator, programs that run well with my simulator are not guarenteed to run at all at the official side. But is is very good to debug your programs and to get a feel for them. Frank Frank Riepenhausen / riepenha@dice2.desy.de From: mrw103@sgi7.york.ac.uk (Matthew Wilcox) Subject: Why not a RISC Core War Message-ID: <1994Nov3.224447.15439@leeds.ac.uk> Date: Thu, 3 Nov 1994 22:44:47 +0000 (GMT) I have only just started at University so I am a newbie to the net but I had read AK Dewdney's book & was interested in Core Wars. The RedCode standard has been altered a lot since then & the proposals look set to make the standard even more complicated. Why not a substantial change towards a RISC architecture for Redcode? RISC processors are a lot easier to program than CISC processors - who programs the Pentium in assembler? The draft 94 standards talk about all sort of addressing modes - is there any need for these modes? Hopefully constructive criticism. Matthew Advanced Risc Machines ARM 7 - 33MHz, 5V, 0.165 Watt, 52 000 Dhrystone 2.1, 36 510 transistors. Nyah to the Pentium Heatsink? What heatsink? -- +=======================================================================+ | If the early bird catches the worm | /| | why does the worm bother getting | Disclaimer : / | | up in the mornings? - R Heinlein | I don't think the University /--| | Matthew Wilcox | care about my opinions / | +=======================================================================+ From: sa7238409@ntuvax.ntu.ac.sg (Angel Dust) Subject: Pre-Newbie Question Date: 4 Nov 94 01:32:15 +0800 Message-ID: <1994Nov4.013215.1@ntuvax.ntu.ac.sg> Sorry to be a drag.... but can anyone enlighten me about what is corewar..... brief descrip welcomed..... also can i play with PC.....don't have Mac or unix AngelDust From: chris@hiram.edu Subject: Re: Why not a RISC Core War Message-ID: <1994Nov4.014639.338@hir800> Date: 4 Nov 94 01:46:39 -0400 In article <1994Nov3.224447.15439@leeds.ac.uk>, mrw103@sgi7.york.ac.uk (Matthew Wilcox) writes: > I have only just started at University so I am a newbie to the net > but I had read AK Dewdney's book & was interested in Core Wars. > The RedCode standard has been altered a lot since then & the proposals > look set to make the standard even more complicated. Why not a > substantial change towards a RISC architecture for Redcode? RISC > processors are a lot easier to program than CISC processors - who huh? Ever tried to program with most of your instructions gone? RISC is much harder on the programmer, but easier(faster) for the CPU. RISC is not popular for it's ease of use, but it's power. Besides, the '86 and '88 standards are pretty bare bones. '94 moves a little more complex, but what command set size would you like to see to call it RISC? All opcodes are fixed length and everything now. I would propose a more CISC standard for the next move. This language is not designed to be run quickly, but to be easy for the programmer to put together a warrior. How about different length instructions? Adding 1 my change the data or change the opcode. comments? > programs the Pentium in assembler? The draft 94 standards talk about > all sort of addressing modes - is there any need for these modes? > probably no. you CAN make your warrior do anything in '88, but the extra codes make it a lot easier on the programmer. And it shortens the code. > Hopefully constructive criticism. Always willing to listen. > Matthew -- Chris Hodson | quis custodet custodes Hiram College | chris@hiram.edu | From: PK6811S@ACAD.DRAKE.EDU Subject: The current Beginner hill: Date: 4 Nov 1994 09:38:12 -0600 Message-ID: <01HJ2S2W04JM0063GO@ACAD.DRAKE.EDU> /+|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+/ / * _________ . * . + . +__ __ * . * / /+ \========\ ____*_______ + ____* /==\* /==\_____ ._______+ ______ + / / . / \ .\/ /====\\===== \_/====\ \ \/\/ /\====\ \======\/=====/ / / \ \____( __ )| | \/\ ___/ + \ /. / __ \_| | \/\___ \ . / / * .\______ / \____/ |__|* \___ / . \__/\ / (____ /|__| /____ / / / . . + \/ + + . * \/ * .\/ + * \/ . + . \/ + / / * . . * . * . . * + / /|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-/ The current Beginner hill: # %W/ %L/ %T Name Author Score Age 1 59/ 31/ 10 Samba2.2 Mr. Jones 188 14 2 57/ 33/ 10 Viewmaster4.0 Ryan Case 181 215 3 56/ 37/ 7 Ecstacy (XTC) Brant Thomsen 175 82 4 37/ 11/ 52 Rabid Dwarfs v1.3 Brian Zellner 162 57 5 41/ 27/ 32 Ox v1.0 Brian Zellner 156 11 6 41/ 36/ 23 Bloody Fang v2.1 Bharat Mediratta 147 2 7 34/ 24/ 42 Slate, v0.3a Bharat Mediratta 143 136 8 35/ 31/ 33 Count Zero #1 Marc Schefer 140 78 9 37/ 35/ 28 Green Knight v1.7 Brian Zellner 139 58 10 31/ 24/ 46 Rubarbe et mort-vivant J.P.Laurin 138 85 11 27/ 17/ 56 Paperous Mr. Jones 138 7 12 30/ 25/ 45 War Machine v2.6 Matthias Wollnik 134 4 13 29/ 25/ 46 War Machine v2.65 Matthias Wollnik 134 3 14 39/ 49/ 11 Cat v2.0 Tim Scheer 129 156 15 38/ 51/ 12 It Hari 125 199 16 26/ 28/ 47 War Machine v2.5 Matthias Wollnik 123 5 17 32/ 42/ 26 AB Scanner 1.0 Chris Hodson 123 1 18 32/ 41/ 27 Rubarbe et grafigne J.P.Laurin 122 84 19 23/ 26/ 51 Mostly Harmless Frank J. T. Wojcik 120 46 20 38/ 57/ 5 Stepper v1.0 Gollum 119 38 21 2/ 98/ 0 Status Check Anonymous 7 0 From: PK6811S@ACAD.DRAKE.EDU Subject: The current ICWS '94 Draft hill: Date: 4 Nov 1994 09:41:13 -0600 Message-ID: <01HJ2S6LCC82005EF2@ACAD.DRAKE.EDU> /+|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+/ / * _________ . * . + . +__ __ * . * / /+ \========\ ____*_______ + ____* /==\* /==\_____ ._______+ ______ + / / . / \ .\/ /====\\===== \_/====\ \ \/\/ /\====\ \======\/=====/ / / \ \____( __ )| | \/\ ___/ + \ /. / __ \_| | \/\___ \ . / / * .\______ / \____/ |__|* \___ / . \__/\ / (____ /|__| /____ / / / . . + \/ + + . * \/ * .\/ + * \/ . + . \/ + / / * . . * . * . . * + / /|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-/ The current ICWS '94 Draft hill: # %W/ %L/ %T Name Author Score Age 1 43/ 31/ 26 Torch t15 P.Kline 154 10 2 45/ 38/ 17 HeremScimitar A.Ivner,P.Kline 153 30 3 46/ 44/ 11 Agony II Stefan Strack 147 146 4 33/ 21/ 46 Jet Black Reptile M R Bremer 145 1 5 34/ 24/ 42 Blue Funk 3 Steven Morrell 144 211 6 37/ 29/ 34 Rude Wind P.Kline 144 60 7 29/ 14/ 57 B-Panama X Steven Morrell 144 152 8 30/ 19/ 51 Silk Warrior 1.4 J.Pohjalainen 142 153 9 42/ 44/ 14 Iron Gate 1.5 Wayne Sheppard 140 500 10 39/ 39/ 22 Leprechaun II Anders Ivner 138 4 11 37/ 36/ 27 Stimpy v2.0 Brant D. Thomsen 138 45 12 30/ 24/ 46 Blue Funk Steven Morrell 137 523 13 38/ 40/ 22 SJ-4 J.Layland 137 212 14 33/ 30/ 36 Killer Instinct II Anders Ivner 136 5 15 28/ 21/ 51 Phoenix 1.2 J.Pohjalainen 135 103 16 30/ 28/ 42 Sasami T.Hsu 132 236 17 37/ 43/ 20 The Spanish Inquisition Steven Morrell 130 39 18 26/ 21/ 53 Aeka T.Hsu 130 166 19 26/ 23/ 51 Bremstone 2.X M R Bremer 129 115 20 26/ 23/ 52 Cannonade P.Kline 128 381 21 2/ 98/ 0 Status Check Anonymous 7 0 From: hbecker@zeus.rbi.informatik.uni-frankfurt.de (Helmar Becker) Subject: Re: Help, novice needs C++Robots Date: 4 Nov 1994 11:32:31 GMT Message-ID: <39d64f$ogt@zeus.rbi.informatik.uni-frankfurt.de> :I have a copy of PCROBOTS and it looks like a nice interface. Seems like more :people are playing C++Robots though. Well, there are some PCRobots fans. Did you create a goot robot yet? I'm searching for a robot which is better than mine. Helmar From: mreddy@glamorgan.ac.uk (Mike Reddy) Subject: Sorry but this is not rec.games.C++ Robots! Message-ID: Date: Fri, 4 Nov 1994 17:00:34 GMT Not sure how to say this but could we have a split here? It seems that rec.games.corewar is a bit of a misnomer at present, with all the C++Robots postings! Yours Mike Reddy -- P.S. I would have had a witty signature, but the Government put VAT on it! P.P.S. I live at mreddy@uk.ac.glamorgan OR mreddy@glamorgan.ac.uk if you are unlucky enough to live outside the UK! 8-) From: rrognlie@netcom.com (Richard Rognlie) Subject: Re: Sorry but this is not rec.games.C++ Robots! Message-ID: Date: Fri, 4 Nov 1994 19:58:35 GMT In article Mike wrote: : Not sure how to say this but could we have a split here? It seems that : rec.games.corewar is a bit of a misnomer at present, with all the C++Robots : postings! I specifically asked rec.games.corewars people if there was an appropriate newsgroup for C++Robots discussions. The response was yes. rec.games.corewars. Apparently, rec.games.corewars's charter is designed to include all programming/AI related games. Since in corewars you program a virus (or whatever you want to call it) that is trying to kill other virii (viruses?) and in C++Robots you are programming a robot, trying to kill other robots the intent is the same. programming skills. : Yours Mike Reddy : -- : P.S. I would have had a witty signature, but the Government put VAT on it! : P.P.S. I live at mreddy@uk.ac.glamorgan OR mreddy@glamorgan.ac.uk if you : are unlucky enough to live outside the UK! 8-) Richard -- /\/\/\ | Richard Rognlie / Sr. Computer Analyst / PRC Inc. / McLean, VA / \ \ \ | E-Mail: rrognlie@netcom.com *or* rognlie_richard@prc.com \ / / / | Phone: (Home) (703) 361-4764 (Office) (703) 556-2458 \/\/\/ | (Fax) (703) 556-1174 From: rrognlie@netcom.com (Richard Rognlie) Subject: Richard's PBeM Server (Monthly Post) Message-ID: Date: Sat, 5 Nov 1994 13:41:16 GMT A generic Play-By-eMail (PBeM) Server has been set up at pbmserv@netcom.com. It currently supports five games (Trax, TwixT, Hex, Abalone and C++Robots) with others to be added in the future. To get more information send mail to pbmserv@netcom.com with 'help' as the subject line. Games Currently Supported Trax ((c) David Smith) Trax is a game played with square tiles. Each tile is identical to all other tiles, one side has a white line connecting opposite edges and a black line connecting the other edges, and the other side has a white line connecting 2 adjacent edges and a black line connecting the other edges. The object of the game is to create a loop of your color while preventing your opponent from doing the same. An alternate winning condition is to create a line extending from one edge of the board to the opposite edge of the board when the board is at least 8 tiles wide (or tall). TwixT ((c) Avalon Hill) On a 24x24 board, players take turns placing pegs of their color on the board. Any time a peg is placed a "knight's move" from another peg of the same color, a strut is placed, connecting them. A strut can not cross over (through) another strut. The object is to connect your sides of the board while preventing your opponent from doing the same. Hex On a 11x11 diamond board, players take turns placing stones of their color on the board. The object is to connect your sides of the board while preventing your opponent from doing the same. Abalone On a hexagonal board (radius 5) two to six players have armies of marbles. Players take turns "pushing" 1, 2 or 3 linearly connected marbles, attempting to push their opponents' marbles off the board. C++Robots ((c) 1994 Richard Rognlie) An ongoing "King of the Hill" (KotH) tournament in which players use the C++ language to create a control program for a robot. Your robot then fights each of the other robots "on the hill". If you do well enough, your robot will "make the hill", bumping the lowest robot from the hill. Robots have the ability to scan for opponents, fire a cannon, move, and determine current position and status. Conceptually based on C-Robots written for the IBM PC by Tom Pointdexter. Games that will be supported in the near future... Terrace (Fall '94) On a terraced 8x8 board, 2 to 4 players take turns attempting to either capture their opponents' key pieces or moving their own key piece to the opposite low corner. The board is terraced so that two opposite corners are low (level 1), and two corners are high (level 8). Unusual movement and capture rules make this game interesting. Nuclear War/Escalation/Proliferation (Winter '95) Humorous card game in which players attempt to blow up their opponents while staying alive themselves. Unfortunately, like the real thing, there are time when nobody wins... -- /\/\/\ | Richard Rognlie / Sr. Computer Analyst / PRC Inc. / McLean, VA / \ \ \ | E-Mail: rrognlie@netcom.com *or* rognlie_richard@prc.com \ / / / | Phone: (Home) (703) 361-4764 (Office) (703) 556-2458 \/\/\/ | (Fax) (703) 556-1174 From: BHBOTHWE@HELIX.watstar.uwaterloo.ca (Hugh Bothwell) Subject: C++Robots, CROBOTS, P-ROBOTS, PC-Robots... Message-ID: Date: Sat, 5 Nov 1994 14:44:50 GMT I have come across mention of a number of similar "design-a-tank" games: CROBOTS - original, by Tom Poindexter - C only on UNIX C++Robots - derived from CROBOTS, C++ only on UNIX P-Robots - highly unrecognized Pascal version of CROBOTS - no-one seems to play it. PC-Robots - enhanced DOS version of CROBOTS/C++Robots - accepts EXE/COM robot files, so you can program in ANY language (assembly, Basic, Pascal, C and C++ are initially supported; anything else you have to write a library for first). I am interested in PC-Robots and, secondarily, C++Robots. Does anyone here know where I can find robot source code/FAQ pages/hint documents for either of these? Hans Becker has a great PC-Robots WWW page (which I lost the address for) at University of Frankfurt; it has nice robots in EXE form, but it includes no source code. Any help/advice would be greatly appreciated. ===================================================================== Hugh Bothwell ! ! F-14D Tomcat bhbothwe@HELIX.watstar.uwaterloo.ca | _ | by Aapool Biman (519) 885-5444 __|__(o)__|__ El. Eng Undergrad --------======/+-+/ . \+-+\======-------- University of Waterloo _____( |_|\___/|_| )_____ Fight to fly Ontario, Canada \__/ * * \__/ Fly to fight / \ Fight to win From: durhamm@news.delphi.com (DURHAMM@DELPHI.COM) Subject: Re: Sorry but this is not rec.games.C++ Robots! Date: 5 Nov 1994 14:47:32 -0000 Message-ID: <39g5u4$98n@news.delphi.com> mreddy@glamorgan.ac.uk (Mike Reddy) writes: >Not sure how to say this but could we have a split here? It seems that >rec.games.corewar is a bit of a misnomer at present, with all the C++Robots >postings! >Yours Mike Reddy >-- C++ Robots is well within the Charter of rec.games.corewar and discussion of the game is most welcome here. For those who have not read the charter of rec.games.corewar, we are open to discussion of all programming games. Mark A. Durham durhamm@delphi.com From: georgel@gas.uug.arizona.edu Subject: Just got an idea for a new opcode in corewars. Date: 5 Nov 1994 19:53:27 GMT Message-ID: <39gnrn$30s@news.CCIT.Arizona.EDU> I just got an idea how to make corewars much more interesting, by adding an instruction that would reverse the flow of the program stream. Instead of down, the stream would suddenly go up. For example if the opcode was named BNC with A-field being where to jump the bounced stream. This would be a reverse IMP: BNC 1 ;reverse the stream flow and jump to 1 MOV 0,-1 ;the reverse IMP Also it could split into reverse and non reverse (BNS in this example) MOV 0,-1 ;reverse IMP start BNS -1 ;split stream off and reverse it to -1, the other continues MOV 0,1 ;regular IMP It would work as a toggle switch so if it were used once the stream flow would go the same direction etc... This would add a whole new dimension to the warriors, as some could be reversed. for example a stun bomb would now have to be JMP 1 SPL 0 JMP -1 It's just a thought so please mail me any comments. If I get the chance I'll try to make a corewar simulator with this opcode, but I don't know C too much. If anybody would do it, that would be great, not that anybody would want to spend a weekend on some stupid idea I had :) George georgel@gas.uug.arizona.edu From: rscott@alpha.netusa.net (Ralph Scott) Subject: Robotwars, original on Apple II Date: 6 Nov 1994 08:56:19 -0500 Message-ID: <39ina3$88b@alpha.netusa.net> Seeing all this discussion on the newer games of the Robotwar variety prompted me to ask this question. I am programming (have programmed) the original robotwars (apple ii) for the pc. It works OK except for the speed of the bullets vs speed of robots vs acceleration type issues. Does anyone still have an old apple with the original robotwars that they can answer some questions for me? This is a long shot request I know! I happen to like the original program better than any/all of the newer variations that have come out. Thanks. ---ralph From: thantos@runic.mind.org (Alexander Williams) Subject: Re: C++Robots, CROBOTS, P-ROBOTS, PC-Robots... Message-ID: Date: Sun, 6 Nov 1994 14:10:58 GMT In article , Hugh Bothwell wrote: >Hans Becker has a great PC-Robots WWW page (which I lost the address for) at >University of Frankfurt; it has nice robots in EXE form, but it includes no >source code. I only wish there was a LISP version; then I could point some of Koza's evolutionary code to the warrior with feedback from a test-suite and evolve the ultimate gladiator. :) -- thantos@runic.mind.org (Alexander Williams) | PGP 2.6 key avail | DF 22 16 CE CA 7F Do What Thou Wilt Shall Be the Whole of the | 98 47 13 EE 8E EC Law. Love is the Law, Love Under Will. -oOo- | 9C 2D 9B 9B From: s004tro@alpha.wright.edu (TIMOTHY OLSON) Subject: Re: Just got an idea for a new opcode in corewars. Message-ID: Date: Sun, 6 Nov 1994 21:38:23 GMT georgel@gas.uug.arizona.edu wrote: > I just got an idea how to make corewars much more interesting, by > adding an instruction that would reverse the flow of the program stream. > Instead of down, the stream would suddenly go up. For example if the > opcode was named BNC with A-field being where to jump the bounced stream. > This would be a reverse IMP: > BNC 1 ;reverse the stream flow and jump to 1 > MOV 0,-1 ;the reverse IMP i used to have a corewar implementation for the ibm pc's which added a similar instruction called PCI which meant "program counter increment". the single argument to PCI was what to add to the current address after execution, so your previous example would look like: mov 0 -1 ;can't the pmars people do something about that annoying comma? pci -1 and you would start at the second instruction. note that this command also allows large-step imps, called SIMPS for super-imps: pci 4 mov 0 4 if one wanted to spread one's code out to make it take longer to core-clear it, one could also use the pci instruction: pci 3 nop nop instruction 1 nop nop instruction 2 ... i don't have this implementation anymore, but i may be able to dig up more info if you want. From: W.Verkley@massey.ac.nz (Wilfred Verkley) Subject: Re: C++Robots, CROBOTS, P-ROBOTS, PC-Robots... Date: Sun, 6 Nov 1994 22:04:56 GMT Message-ID: >I have come across mention of a number of similar "design-a-tank" games: >CROBOTS - original, by Tom Poindexter - C only on UNIX >C++Robots - derived from CROBOTS, C++ only on UNIX >P-Robots - highly unrecognized Pascal version of CROBOTS - no-one seems > to play it. >PC-Robots - enhanced DOS version of CROBOTS/C++Robots - accepts EXE/COM robot > files, so you can program in ANY language (assembly, Basic, Pascal, C > and C++ are initially supported; anything else you have to write a > library for first). Most of the C++ robots ive seen dont do anything better then their C counterparts. P-Robots has much more potential the CROBOTS and derivitives. While C/C++ robots still uses the same world, P-ROBOTS allows things like bombs, cloaking, different engines, different arnaments, healing. It also has a neat concepts of different robot configuration, where you can put weights on each of these properties out of a certain number of points. I suppose if you want to get really advanced, we would all be writting auto-pilots for the mac-game bolo. From: lloyda@nuge111.its.rpi.edu Subject: Redcode Manual??? Date: 6 Nov 1994 22:09:41 GMT Message-ID: <39jk75$pao@usenet.rpi.edu> I have just compiled corewars and am now interested in getting the redcode manual, if such a thing exists. If anybody knows the location or has this thing, i would like to get a hold of it. Please email it to me, or post it's location for the good of the other newbies. Thanx a'plenty. SOUTH South ( like the direction ) Lloyd lloyda@rpi.edu == south@gunbuster.stu.rpi.edu RPI CSCI "Fung U Cung Kung, Yung O U" -ancient double-chinese wisdom From: georgel@gas.uug.arizona.edu Subject: P-Robots for DOS Date: 7 Nov 1994 02:41:21 GMT Message-ID: <39k44h$5d8@news.CCIT.Arizona.EDU> Since some people were talking about p-robots for mac, I tried to find them for DOS to try them. I just got them so I don't know how they work or anything, and I don't even know how c-robots work, but I know pascal so I wanted to try it. I found it on gopher.archive.merit.edu in /msdos/games/strategy/ and it is called probots.zip Well I'm gonna try to learn how they work, but if anybody who knows robots can help me e-mail me. Thanx georgel@gas.uug.arizona.edu From: schoelle@cs.tu-berlin.de (Bernd Schoeller) Subject: OMEGA - Still someone there ? Date: 7 Nov 1994 21:29:17 GMT Message-ID: <39m67d$3fk@news.cs.tu-berlin.de> Hello ! Is there still someone outthere playing the old game from Origin called OMEGA ? No, I do not mean this D&D-Style game, but the tank design and programming games ... Ciao, Bernd -- schoelle@cs.tu-berlin.de From: mrw103@figaro.york.ac.uk (Matthew Wilcox) Subject: Re: Why not a RISC Core War Message-ID: <1994Nov7.230049.12716@leeds.ac.uk> Date: Mon, 7 Nov 1994 23:00:49 +0000 (GMT) chris@hiram.edu wrote: : huh? Ever tried to program with most of your instructions gone? RISC : is much harder on the programmer, but easier(faster) for the CPU. RISC : is not popular for it's ease of use, but it's power. I can program in ARM assembler ... does anyone claim to program a Pentium in assembler? True, not all RISC's are easy to program; I'm told that the Power PC is not easy but I think the Berkley RISC was. : Besides, the '86 and '88 standards are pretty bare bones. '94 moves : a little more complex, but what command set size would you like to : see to call it RISC? All opcodes are fixed length and everything now. : I would propose a more CISC standard for the next move. This language : is not designed to be run quickly, but to be easy for the programmer : to put together a warrior. How about different length instructions? : Adding 1 my change the data or change the opcode. comments? Depends what you mean by easy for the programmer. When you have all these different addressing modes, things start to get really complicated (maybe it's just my lack of comprehension here). : > programs the Pentium in assembler? The draft 94 standards talk about : > all sort of addressing modes - is there any need for these modes? : > : probably no. you CAN make your warrior do anything in '88, but the extra : codes make it a lot easier on the programmer. And it shortens the code. : > Hopefully constructive criticism. : Always willing to listen. Glad to hear it! Matthew -- +=======================================================================+ | If the early bird catches the worm | /| | why does the worm bother getting | Disclaimer : / | | up in the mornings? - R Heinlein | I don't think the University /--| | Matthew Wilcox | care about my opinions / | +=======================================================================+ From: jesensky@mix.cse.psu.edu (James J Jesensky) Subject: Re: C++Robots, CROBOTS, P-ROBOTS, PC-Robots... Date: 7 Nov 1994 23:22:08 GMT Message-ID: <39mcr1$ckf@psuvax1.cse.psu.edu> In article BHBOTHWE@HELIX.watstar.uwaterloo.ca (Hugh Bothwell) writes: >I have come across mention of a number of similar "design-a-tank" games: > >CROBOTS - original, by Tom Poindexter - C only on UNIX > I have a copy of CROBOTS that runs on PC. It's been so long, I don't remember if I compiled the source myself or it came with the registered version. -- Jim From: jesensky@mix.cse.psu.edu (James J Jesensky) Subject: Other Prog. Games (was Re: C++Robots, CROBOTS, P-ROBOTS, PC-Robots...) Date: 7 Nov 1994 23:28:41 GMT Message-ID: <39md79$cpt@psuvax1.cse.psu.edu> In article BHBOTHWE@HELIX.watstar.uwaterloo.ca (Hugh Bothwell) writes: >I have come across mention of a number of similar "design-a-tank" games: [...] >Any help/advice would be greatly appreciated. There was a game Omega (Amiga I think?) were you wrote tank programs--I believe the nice thing about Omega is that you had terrain (trees, water, elevation, etc.). A couple years ago I looked at xtank as a programming game. I found it too hacked together and too poorly documented. Is xtank still around? I would also like to hear about programming games other than Corewars. Jim From: pk6811s@acad.drake.edu Subject: '94 changes - preliminary eval Date: 8 Nov 94 09:05:16 CST Message-ID: <1994Nov8.090516@acad.drake.edu> > > : > programs the Pentium in assembler? The draft 94 standards talk about > : > all sort of addressing modes - is there any need for these modes? > : > > : probably no. you CAN make your warrior do anything in '88, but the extra > : codes make it a lot easier on the programmer. And it shortens the code. > Since 1994 is almost gone, maybe it's time for an evaluation of the '94 draft. What have people found useful? And what useless? Here are some ideas: SNE, SEQ: Used in combination for quick-scanners which dominated the hill for a short while. Basically useful for killing large, slow-starting opponents like imp-spirals and paper colonies. post-increment modifiers, > and }: Used for forward clearing and djn-streams. Torch uses > to implement the mov/spl bomb. Torch and HeremScimitar use post-increment for this continuous core-clear and gate: sb spl #step,0 clr mov bmb,>-13 djn.f clr,{-14 bmb dat <4,step+step a-field addressing: Used along with post-increment in Silk and B-Panama, to make a very strong replicator. Also used by T. Hsu to minimize imp-launching time. legalizing all address forms: SPL #step,#-step saves an instruction and locks in the spl-zero action even if the instruction is added-to or subtracted-from DJN.F stronger djn-streams - decrementing both the a and b fields MOV.I #value,2667 somewhat stronger imps (they already were tough!) SNE.X Rude Wind uses this to distinguish imps from djn.f streams (it compares the a-field of one location to the b-field of the other - and vica-versa) Others? Paul Kline pk6811s@acad.drake.edu From: hbecker@zeus.rbi.informatik.uni-frankfurt.de (Helmar Becker) Subject: Re: C++Robots, CROBOTS, P-ROBOTS, PC-Robots... Date: 8 Nov 1994 09:49:37 GMT Message-ID: <39nhjh$gju@zeus.rbi.informatik.uni-frankfurt.de> > >PC-Robots - enhanced DOS version of CROBOTS/C++Robots - accepts EXE/COM robot > > files, so you can program in ANY language (assembly, Basic, Pascal, C > > and C++ are initially supported; anything else you have to write a > > library for first). > P-Robots has much more potential the CROBOTS and derivitives. While C/C++ > robots still uses the same world, P-ROBOTS allows things like bombs, > cloaking, different engines, different arnaments, healing. It also has a > neat concepts of different robot configuration, where you can put weights on > each of these properties out of a certain number of points. Do you really mean P-Robots? I have a version of P-Robots, which doesn't have these features. PCRobots has these features! Bye... Helmar From: hbecker@zeus.rbi.informatik.uni-frankfurt.de (Helmar Becker) Subject: Re: C++Robots, CROBOTS, P-ROBOTS, PC-Robots... Date: 8 Nov 1994 10:11:47 GMT Message-ID: <39nit3$gju@zeus.rbi.informatik.uni-frankfurt.de> > CROBOTS - original, by Tom Poindexter - C only on UNIX There's a DOS version, too. > P-Robots - highly unrecognized Pascal version of CROBOTS - no-one seems > to play it. I know 2 (two! :-) people who worked with P-Robots (in German FidoNet) > PC-Robots - enhanced DOS version of CROBOTS/C++Robots - accepts EXE/COM robot > files, so you can program in ANY language (assembly, Basic, Pascal, C > and C++ are initially supported; anything else you have to write a > library for first). > > I am interested in PC-Robots and, secondarily, C++Robots. Does anyone here > know where I can find robot source code/FAQ pages/hint documents for either > of these? I want to know about this, too. In addition, I'm searching for the "superfast" PCRobots version (without graphic output) which should be available (the doc says so). I tried to contact the author (P.D.Smith), but without success. > Helmar Becker has a great PC-Robots WWW page at > University of Frankfurt; Still under construction; URL: http://www.uni-frankfurt.de/~hbecker/pcrob.html There are DOS-versions of C-Robot and P-Robot, too. > it has nice robots in EXE form, but it includes no > source code. Give me sources, and I will include them! I'll include some sources I have already, too. Bye... Helmar Subject: Help (C++Robots) Message-ID: <1994Nov8.120917@zipi.fi.upm.es> From: a920258@zipi.fi.upm.es Date: 8 Nov 94 12:09:17 +0100 HI! Errr...Where Can i find C++Robots, i like to program in C++ and i want Thanx in Advance... to catch the program. From: hanwen@axe.stack.urc.tue.nl (Han-Wen Nienhuys) Subject: For making it up (C++Robots source listing) Date: 8 Nov 1994 15:09:24 GMT Message-ID: <39o4b4$3vr@tuegate.tue.nl> Hi Guys... Sorry for occupying too many places in the C.R. Hill. Here one of the robots I deleted. ******* Perp II, The Return of the TrackerTerminator. BEGIN #include "robots.h" main () { int a,d,AFW,dra,lda,da; lda = -100; while (1) { if (d= scan(a,10)) { cannon(a,d); cannon(a,d); dra = a+ 6000/d; drive (dra, 100 - 4000/d); a -= 2000/d + 1; } else { a+=19; } } } ***** greetings, /HaWee/ {fido: 2:284/102.27,email: hanwen@stack.urc.tue.nl} From: mreddy@glamorgan.ac.uk (Mike Reddy) Subject: Re: Sorry but this is not rec.games.C++ Robots! Message-ID: Date: Tue, 8 Nov 1994 16:18:02 GMT I apologise most whole-heartedly. It seems I fired off half-cocked from the email I received 8-) Clearly, C++ Robots is taking off in a rather successful way; my personal concern was that it was swamping the newsgroup, but if you say it is within the remit of the group, then fair enough. Sorry for any unintended flame bait! Yours Mike Reddy -- P.S. I would have had a witty signature, but the Government put VAT on it! P.P.S. I live at mreddy@uk.ac.glamorgan OR mreddy@glamorgan.ac.uk if you are unlucky enough to live outside the UK! 8-) Snail Mail: Mike Reddy, J228, Dept. of Computer Studies, University of Glamorgan, Pontypridd, Mid Glamorgan. CF37 1DL Wales, UK Tel: +44 (0)443 482 240 Fax: +44 (0)443 482 715 From: ccoop@teleport.com (Christopher Cooper) Subject: OMEGA Anyone? Date: 8 Nov 1994 22:48:00 -0800 Message-ID: <39prb0$3ur@elaine.teleport.com> Since the rec.games.corewars charter includes any game that involves competing programmers in a game interface, I thought I'd initiate an OMEGA discussion. I do not own a PC version of the cybertank programming game from Origin Systems, Inc., and am on the look out. If anyone knows of someone who wants to sell or trade me their copy (docs a must), please email me. I used to play the game in the late 80's and found it very challenging and rewarding. I beat all the tanks that came with the game, and stopped playing it after that. Then I sold my Amiga (ameoba to some). I have heard that there are still enthusiasts out there and I would like to hear from any interested in a tourney or even a simple competition. I contacted Origin Systems today (now owned by Electronic Arts) and they are not selling OMEGA. I have faxed their marketing department to find out if a special release could be arranged for Internet players, since the swapping of cybertank files is ideal for this type of communication. No answer yet of course. I'm also interested if anyone would like to become involved in improving OMEGA. In other words, collaborate on a project to make a better programming game with up to date graphics and a more realistic language. Let me know what you think. -- ccoop@teleport.COM Public Access User --- Not affiliated with Teleport Public Access UNIX and Internet at (503) 220-1016 (2400-14400, N81) From: bdthomse@peruvian.cs.utah.edu (Brant Thomsen) Subject: Re: '94 changes - preliminary eval Date: 9 Nov 1994 04:07:02 GMT Message-ID: <39pht6$1pg@magus.cs.utah.edu> In article <1994Nov8.090516@acad.drake.edu> pk6811s@acad.drake.edu writes: >Since 1994 is almost gone, maybe it's time for an evaluation of the '94 draft. >What have people found useful? And what useless? Here are some ideas: >a-field addressing: > Used along with post-increment in Silk and B-Panama, to make a very strong >replicator. Also used by T. Hsu to minimize imp-launching time. Probably the biggest impact I have felt from this item has been the much greater ease and power available to authors of anti-vampiric programs. >Others? > Stimpy uses the JMZ.F command for a A/B-field scanner. The use of modifiers has opened new doors for other scanner types as well. Any word yet on when the next draft of the '94 standard will be out? Are we going to need to go to a '95 standard? (If we do, what will I call my newsletter?! ;-) -- Brant D. Thomsen Man will occasionally stumble over the truth, (bdthomse@peruvian.cs.utah.edu) but most times he will pick himself up University of Utah and carry on. - Winston Churchill From: dolan@uwast.astro.wisc.edu (Chris Dolan) Subject: C++Robots source: scanbot3.c Date: 9 Nov 1994 21:08:18 GMT Message-ID: <39rdo2$6ij@news.doit.wisc.edu> Here are some handy scripts I wrote for C++Robots: >>> build.sh <<< Turns all lines beginning with // into C++Robots comments #!/bin/csh grep "^//" $1 | sed s/'\/\/ '// echo BEGIN grep -v "^//" $1 echo END >>> submit.sh <<< Mails robot into hill (e.g. submit.sh scanbot3.c scanbot) #!/bin/csh if ($1"q" != "q" && $2"q" != "q") then build.sh $1 | mail -s "C++Robots program $2 passwd" pbmserv@netcom.com else echo Syntax: $0 \ \ endif This is my best robot to date (not really that great though): // scanbot3.c by Chris Dolan // Scans for enemy, shoots and charges. Has 3 scan modes: coarse, medium and // fine. Shoots 3 bullets each time it finds an enemy (good improvement on // shooting time/scanning time ratio). #include "robots.h" #define True 1 #define False 0 /* For wide scans, use coarsest resolution (21 degree width, +-10) Inside range threshhold 1, just do medium scans (7 degree width, +-3) Inside range threshhold 1, do intermdiate-tight scans (3 degree width, +-1) For anything further, use maximum resolution (1 degree width, +-0) */ #define RANGETHRESH1 500 #define RANGETHRESH2 1500 /* Do not fire a cannon closer than this range */ #define CANNON_MIN 201 /* 201 ==> 1 point of damage to me */ /* wide is last known angle to enemy */ /* Start wide=(number>>0) so we never get negative value (wide%360 < 0 if wide < 0) */ static int wide=720; /* Fire cannon 3 times */ int cannon3(int dir, int range) { return cannon(dir, range) + cannon(dir, range) + cannon(dir, range); } /* Replace all subsequent occurrences of cannon() with cannon3() */ #define cannon cannon3 /* Just look around as quickly as possible to get a rough direction to enemy */ void widescan(void) { register int range; for (; True; wide += 20) { range = scan(wide, 10); if (range > 0) { return; } } } /* Fine resolution search for enemy. The farther away the enemy is, the finer resolution we need to shove a cannon shell right up his butt */ int tightscan(int range) { register int r, i; if (range > RANGETHRESH1) { /* finer scan, else just leave it alone */ if (range > RANGETHRESH2) { /* finest scan */ for (i=-3;i<=3;i++) { r = scan(wide+i, 0); if (r > 0) { wide = wide+i; return r; } } } else { for (i=-3;i<=3;i+=3) { r = scan(wide+i, 1); if (r > 0) { wide = wide+i; return r; } } } } return range; } /* Scan, charge, shoot, not necessarily in that order */ /* Check left, middle, right in that order since widescan goes right to left */ main(void) { register int range; widescan(); while (1) { drive(wide, 100); /* Charge! */ range = scan(wide+7, 3); /* check left... */ if (range > 0) { wide += 7; range = tightscan(range); cannon(wide, (range>=CANNON_MIN ? range : CANNON_MIN)); } else { range = scan(wide, 3); /* check middle... */ if (range > 0) { range = tightscan(range); cannon(wide, (range>=CANNON_MIN ? range : CANNON_MIN)); } else { range = scan(wide-7, 3); /* check right */ if (range > 0) { wide -= 7; range = tightscan(range); cannon(wide, (range>=CANNON_MIN ? range : CANNON_MIN)); } else { /* Damn, lost him... Back up a few and re-scan*/ /* drive(wide, 0); */ /* Don't hit a wall! */ wide -= 20; widescan(); } } } } } From: jesensky@mix.cse.psu.edu (James J Jesensky) Subject: Scoring Inaccuracies (Which Program Runs First?) Date: 9 Nov 1994 23:54:23 GMT Message-ID: <39rnff$2ct@psuvax1.cse.psu.edu> When running two programs for multiple battles, there seems to be the belief that for each starting address, two battles should be fought: one with program A executing first and one with program B executing first. This practice however causes scoring inaccuracies (see why below). It is not practical to calculate the "true score" of two programs since it would require running many thousands of battles. Therefore we take a sample of the possible outcomes (for instance 100). The outcome of a particular battle is a function of two random variables: the starting displacement and execution order. By not letting these variables be truely random across their domains, we are not getting as close to the true score as we like. For example: Consider if a simple bomber start mov -1, <-1 jmp -1 end start was run against itself in a core size 8000. The only displacement that can cause a different outcome based on execution order is 4000. By running each program twice per displacement, we are effectively running half as many matches and multipling the result by 2. This GREATLY reduces the percent of confidence we can claim that our calculated score is within a certain range of the true score. While with more complex programs, execution order may play a more deciding role, again we are placing a non-random condition of a random varible. Some may feel this is a good thing; however, there is another element added in koth type tournaments. Suppose Prog X tends to perform the same reguardless of execution order and Prog Y tends to perfrom differently based on execution order. Both Prog X and Prog Y are submitting to a koth. Since each battle is fought twice per displacement, the scoring methods used to score X and Y will not be same--Prog X's calculated score will have a greater chance to be far higher or far lower from its true score as would Prog Y. The only way to score X and Y fairly would be to randomly select a displacement each battle and also randomly select an execution order each battle. A final note: There is also no reason that each program should go first 50% of the time. Proposal: For each battle between two Corewar programs, a new random starting displacement and a new random execution order should be selected. Commments? Jim P.S. Please excuse my statistics--I am not a stats wizard. From: pk6811s@acad.drake.edu Subject: Re: Scoring Inaccuracies (Which Program Runs First?) Date: 10 Nov 94 15:22:55 CST Message-ID: <1994Nov10.152255@acad.drake.edu> In article <39rnff$2ct@psuvax1.cse.psu.edu>, jesensky@mix.cse.psu.edu (James J Jesensky) writes: > When running two programs for multiple battles, there seems to be the > belief that for each starting address, two battles should be fought: > one with program A executing first and one with program B executing > first. This practice however causes scoring inaccuracies (see why below). > > other comments cut < Two opponents each 12 instructions long. One scans forward using a step of 8, the other scans backward using a step of 10. Which one will discover the other first no matter what the starting positions or starting sequence? Two opponents each 4 instructions long. One scans forward using a step of 4, the other scans backward using a step of 5. Which one will discover the other first in exactly 80% of the battles using all possible starting positions? Two opponents each 12 instructions long. One scans forward using a step of 8, the other scans forward using a step of 10. Which one will discover the other first in exactly 55% of the battles using all possible starting positions? Given the variety of scan/bomb steps in-use the last example is the most typical. In this case the choice of starting positions can affect the outcome. When a different set of starting positions was used with every submission you could see a change of +/- 10 wins against individual opponents even though you did not change your code, (but usually they averaged out against 20 so there was no hope of continually resubmitting just to increase your score). I agree that the outcome against individual opponents is partially determined by the choice of starting positions, but you can always run more battles 'at home' to get the exact score. Running more battles on the Hills means asking those machine owners to donate more cpu's to the game... I do agree that repeating battles at the same starting position but reversing the starting order is a waste of time. Whether I get one more cycle than you do isn't going to make any difference in 99% of the battles. It's better to use two different starting positions. I suggest letting the challenger go first in ALL battles. Paul Kline pk6811s@acad.drake.edu From: Michael N Nonemacher Subject: Re: '94 changes - preliminary eval Date: Thu, 10 Nov 1994 15:25:12 -0500 Message-ID: <0ikc6cq00WBOQ8E1dl@andrew.cmu.edu> Don't forget NOP, which was used (but not exactly *required*) in Ryooki. From: chris@hiram.edu Subject: Re: '94 changes - preliminary eval Message-ID: <1994Nov10.155916.340@hir800> Date: 10 Nov 94 15:59:16 -0400 In article <1994Nov8.090516@acad.drake.edu>, pk6811s@acad.drake.edu writes: > Since 1994 is almost gone, maybe it's time for an evaluation of the '94 draft. > What have people found useful? And what useless? Here are some ideas: [snip] > Paul Kline > pk6811s@acad.drake.edu I am a newbie, but let me tell you my story. I first started redcoding(?) in '88 code, but was confused and frustrated by the lack of some opcode and combinations(why was > left out ?). I had ideas, but I couldn't implement many of them. When I moved to '94, learned what it had to say, then only used what I needed, it was much easier. As I said, I don't NEED those extra modes, but it would have saved me much confusion in the startup period. As for looking toward the future, I notice quite a few "how about this" postings that no one comments either way on. Maybe a collection of these(albeit sometimes wacky) ideas and a good discussion might help shape the way of things to come. -- Chris Hodson | quis custodet custodes Hiram College | chris@hiram.edu | From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) Subject: Re: Scoring Inaccuracies (Which Program Runs First?) Date: 10 Nov 1994 21:19:45 GMT Message-ID: <39u2ph$ig6@agate.berkeley.edu> James J Jesensky wrote: >Proposal: For each battle between two Corewar programs, a new random >starting displacement and a new random execution order should be selected. The way that pMARS currently operates is that it will choose 100 random starting locations, and the first program will go first for the first half of the battles and the second program will go first for the last half of the battles. There are 100 starting locations chosen, not 50. Why would choosing random execution order be fairer than having each program go first half of the time? In fact, what *could* be fairer than having each program go first half of the time? -- Michael Constant (mconst@soda.csua.berkeley.edu) From: jesensky@mix.cse.psu.edu (James J Jesensky) Subject: Re: Scoring Inaccuracies (Which Program Runs First?) Date: 10 Nov 1994 23:39:56 GMT Message-ID: <39ub0c$b00@psuvax1.cse.psu.edu> In article <39u2ph$ig6@agate.berkeley.edu> mconst@soda.CSUA.Berkeley.EDU (Michael Constant) writes: >James J Jesensky wrote: >>Proposal: For each battle between two Corewar programs, a new random >>starting displacement and a new random execution order should be selected. > [...] > >Why would choosing random execution order be fairer than having each >program go first half of the time? In fact, what *could* be fairer than >having each program go first half of the time? >-- > Michael Constant (mconst@soda.csua.berkeley.edu) The problem is trying to be fair. Why not ensure that the distance between two programs is even 50% of the time and odd 50% of the time. Where would would end? Maybe "fair" is a bad term. Inconsistant may be is more accurate. Think of this way: suppose I did a phone survey by calling 200 people randomly in the USA and asked "Is is the weather cold or hot outside?" Then you called 100 people and their next-door-neighboor and asked the same question. My survey would have a much better chance to more accurately represent the average weather accross the USA than yours since each of your calls and their neighboor would say the same responce--there is the inaccuracy part. Suppose you would have asked "Are your eyes blue, brown, or green?" using the same calling method (100+neighboor). This time your method would create no inaccuracy since eye color and who you live next to have nothing in common. The fact the same survey method (staring programs method) can vary in accuracy for different questions (programs) is the inconsistant or fairness part. Jim From: jesensky@mix.cse.psu.edu (James J Jesensky) Subject: [C++Robots] stush.c Date: 11 Nov 1994 00:02:13 GMT Message-ID: <39uca6$bfe@psuvax1.cse.psu.edu> Suggestion: If your post is non-Corewar or non-general audience, indicate so on the subject line (see above). Here is stush.c currently #9 on the c++robots koth. Stush.c is a very simple program. Stushu.c (currently #4) and turbostush.c (currently #6) are improved versions of stush.c. BEGIN //stush.c //James Jesensky #include "robots.h" main() { int d=45, f=0, r, x, y, flag=0; while(1) { drive(d,100),x=loc_x(), y=loc_y(); if (x<1000 && d==135) d=45; else if (x<1000 && d!=45) d=315; else if (x>9000 && d==45) d=135; else if (x>9000 && d!=135) d=225; if (y<1000 && d==315) d=45; else if (y<1000 && d!=45) d=135; else if (y>9000 && d==45) d=315; else if (y>9000 && d!=315) d=225; if (flag) { if (r=scan(f,10)) cannon(f,r); else if (r=scan(f+20,10)) f+=20; else if (r=scan(f-20,10)) f-=20; else flag = 0; if (r=scan(f,10)) cannon(f,r); } else { f+=85; if (r=scan(f,10)) { cannon(f,r); flag=1; } } } } END From: "Nathan T. Wild" Subject: W3 Date: Fri, 11 Nov 1994 01:36:21 -0600 Message-ID: I will be setting up a WWW page for PCRobots and potentially C/C++Robots. If anyone has any interesting source files or prefereably nifty scanning algorithms, please send them to me. I will make a formal announcement as the page is completed... If anyone has any recomendation... please let me know ASAP... Please respond via email to the following address... Later: Nate... ------------------------------------------------------------------------ | Nathan T. Wild | Retail Systems | (204) 631-7378 VOX | | natewild@mbnet.mb.ca | Codville Distributors | (204) 694-2948 FAX | ------------------------------------------------------------------------ - A C++ Programmer Is Always Willing To Try New Things - From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) Subject: Re: Scoring Inaccuracies (Which Program Runs First?) Date: 11 Nov 1994 06:42:44 GMT Message-ID: <39v3p4$4pj@agate.berkeley.edu> James J Jesensky wrote: >mconst@soda.CSUA.Berkeley.EDU (Michael Constant) writes: >>James J Jesensky wrote: >>>Proposal: For each battle between two Corewar programs, a new random >>>starting displacement and a new random execution order should be selected. >> >>Why would choosing random execution order be fairer than having each >>program go first half of the time? In fact, what *could* be fairer than >>having each program go first half of the time? > >The problem is trying to be fair. Why not ensure that the distance between >two programs is even 50% of the time and odd 50% of the time. Where would >it end? It's a question of how fair we can reasonably expect to be. In the case of starting location, there are 7800 different possibilities, so we can't expect to try them all. Instead, the fairest method is to choose a random sample. The more random the sample, the fairer it will be -- as you noted. However, in the case of execution order, there are only two different possibilities. Either you go first, or I do. Therefore, it *is* now feasible to, using the statistcal language, sample the entire population. To use your example, we can call up every single person in the U.S. to ask them what the weather is like. In fact, we can even try each one more than once (the only reason we do this is so that we can vary the starting location, but that's beside the point). So, while it is impossible to be perfectly fair with the starting location, it *is* possible to be perfectly fair with the execution order. And when it is possible to be perfectly fair, I think you will agree that that is better than any other method of deciding who goes first... -- Michael Constant (mconst@soda.csua.berkeley.edu) From: natey@merle.acns.nwu.edu (Nathan Yawn) Subject: [C-Robots] Anyone have a .PRJ to compile cbots? Date: 12 Nov 94 02:49:19 GMT Message-ID: I recently downloaded the source C code for Cbots by Bharat Mediratta. It included a "Makefile," but this is useless to my Borland C compiler (version 3.1, if that's important). I'm really not quite sure how to put all the source files togeather to compile them. If someone has the .PRJ project file (and would be kind enough to post it) I'd be most grateful. Also if you could tell me where to FTP tutorials and helpfiles for C-bots, I'd appreciate. If that's listed in the FAQ, then please tell me where to get that. Thankee. Nate "Don't make me" Yawn natey@merle.acns.nwu.edu From: haha@beta.hut.fi (Harri Haanp{{) Subject: Re: Scoring Inaccuracies (Which Program Runs First?) Date: 12 Nov 94 10:35:05 GMT Message-ID: pk6811s@acad.drake.edu writes: >I do agree that repeating battles at the same starting position but reversing >the starting order is a waste of time. Whether I get one more cycle >than you do isn't going to make any difference in 99% of the battles. It's >better to use two different starting positions. I suggest letting the >challenger go first in ALL battles. The only advantage of repeating battles at the same starting position would be that when a program is fighting itself, it'd get the same amount of wins and losses. To achieve the same effect when a program is up against itself we could just run half the number of matches and let wins = losses = wins + losses; ties = 2*ties; As for who should begin.. of course if we disregard the minor advantage of starting, it doesn't make any difference which program starts. If we do take that advantage into consideration, we certainly had better make sure each program gets to start as many times. To choose the starter of each match at random would only increase the variance and therefore require more matches to be run to get as reliable a result. Consider a game of soccer or ice-hockey that's gone to a penalty shootout. Each team gets 5 penalty shots and whichever team has more goals after that is declared winner. Now consider the following modification: There will be a total of 10 penalty shots. Before each shot, the team that gets to take it is picked at random. Now, the expected result is the same, but luck plays a more important part - the variation is greater. Therefore it's better to let each program begin as many matches than to choose the starter randomly for each match. Harri From: bharat@Eng.Sun.COM (Bharat Mediratta) Subject: Re: [C-Robots] Anyone have a .PRJ to compile cbo Date: 13 Nov 1994 00:31:16 GMT Message-ID: <3a3mok$4o6@engnews2.Eng.Sun.COM> In article 784608559@merle, natey@merle.acns.nwu.edu (Nathan Yawn) writes: > I recently downloaded the source C code for Cbots by Bharat Mediratta. > It included a "Makefile," but this is useless to my Borland C compiler >(version 3.1, if that's important). I'm really not quite sure how to put all >the source files togeather to compile them. If someone has the .PRJ project >file (and would be kind enough to post it) I'd be most grateful. > > Also if you could tell me where to FTP tutorials and helpfiles for >C-bots, I'd appreciate. If that's listed in the FAQ, then please tell me >where to get that. Thankee. Alas, Cbots has not been tested on a PC (which is what I'm assuming you're trying to run it on.) In fact, I'd be blown away if it worked on a PC unless you are running Linux. Cbots uses shared memory and X calls for the front end, so you're out of luck in PC land. I'd try using CROBOTS by Tom Poindexter. -Bharat --- Bharat Mediratta | Above opinions are mine and have bharat.mediratta@corp.sun.com | nothing to do with Sun Microsystems From: bmellows@jolt.mpx.com.au (Bruce Mellows) Subject: Re: Scoring Inaccuracies (Which Program Runs First?) Date: 13 Nov 1994 00:50:04 GMT Message-ID: <3a3nrs$g4o@inferno.mpx.com.au> Michael Constant (mconst@soda.CSUA.Berkeley.EDU) wrote: : James J Jesensky wrote: : >mconst@soda.CSUA.Berkeley.EDU (Michael Constant) writes: : >>James J Jesensky wrote: : >>>Proposal: For each battle between two Corewar programs, a new random : >>>starting displacement and a new random execution order should be selected. : >> : >>Why would choosing random execution order be fairer than having each : >>program go first half of the time? In fact, what *could* be fairer than : >>having each program go first half of the time? : > : >The problem is trying to be fair. Why not ensure that the distance between : >two programs is even 50% of the time and odd 50% of the time. Where would : >it end? : It's a question of how fair we can reasonably expect to be. In the case : of starting location, there are 7800 different possibilities, so we can't : expect to try them all. Instead, the fairest method is to choose a random : sample. The more random the sample, the fairer it will be -- as you noted. : However, in the case of execution order, there are only two different : possibilities. Either you go first, or I do. Therefore, it *is* now : feasible to, using the statistcal language, sample the entire population. : To use your example, we can call up every single person in the U.S. to : ask them what the weather is like. In fact, we can even try each one : more than once (the only reason we do this is so that we can vary the : starting location, but that's beside the point). : So, while it is impossible to be perfectly fair with the starting : location, it *is* possible to be perfectly fair with the execution : order. And when it is possible to be perfectly fair, I think you will : agree that that is better than any other method of deciding who goes : first... : -- : Michael Constant (mconst@soda.csua.berkeley.edu) I've been thinking about modifying (sp?) pMARS to my own batch MARS, with the option of having the same starting position and both players start once each, if you get my meaning, thereby lessening the impact of lucky stating positions/order. I'm not saying "coming to you this ..." (it is firstly for my own use), but perhaps some bright achiever might try this and see. Bruce Mellows (bmellows@mpx.com.au) From: rschuler@iastate.edu (Rodney Schuler) Subject: Re: Scoring Inaccuracies (Which Program Runs First?) Date: 13 Nov 1994 05:07:21 GMT Message-ID: <3a46u9$770@news.iastate.edu> In article <39v3p4$4pj@agate.berkeley.edu>, Michael Constant wrote: >James J Jesensky wrote: >>mconst@soda.CSUA.Berkeley.EDU (Michael Constant) writes: >>>James J Jesensky wrote: >>>>Proposal: For each battle between two Corewar programs, a new random >>>>starting displacement and a new random execution order should be selected. How about using pseudo-random numbers for choosing starting location? A pseudo-random sequence (like Sobol's sequence) might give more uniform results. Pseudo-random numbers have a much more uniform distribution than random numbers and are gaurenteed not to repeat until the entire space has been sampled. If anybody wishes, I can post some C code and a better explanation of pseudo-random numbers. Rodney Schuler Nuclear Engineering 186,282 miles per second Iowa State University Its Not Just a Good Idea rschuler@iastate.edu ITS THE LAW! From: Michael N Nonemacher Subject: Re: Scoring Inaccuracies (Which Program Runs First?) Date: Sun, 13 Nov 1994 20:59:57 -0500 Message-ID: Excerpts from netnews.rec.games.corewar: 12-Nov-94 Re: Scoring Inaccuracies (W.. by Harri Haanp{{@beta.hut.f > The only advantage of repeating battles at the same starting position > would be that when a program is fighting itself, it'd get the same > amount of wins and losses. To achieve the same effect when a program > is up against itself we could just run half the number of matches and > let > > wins = losses = wins + losses; > ties = 2*ties; I disagree. Drowning III just got a score of 52 wins, 4 ties against itself... :-) I'm figuring the "real" outcome would be around 48-48-4, so the current scoring method added 0.6 point to my total KotH score. I'll take it. Mike From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) Subject: Re: Scoring Inaccuracies (Which Program Runs First?) Date: 13 Nov 1994 23:00:33 GMT Message-ID: <3a65qh$scn@agate.berkeley.edu> Bruce Mellows wrote: >I've been thinking about modifying (sp?) pMARS to my own batch MARS, with >the option of having the same starting position and both players start once >each, if you get my meaning, thereby lessening the impact of lucky >stating positions/order. I'm not sure I quite understand what you mean here. Are you saying that in your MARS, you would run 100 battles like this: * location 1, prog A goes first * location 1, prog B goes first * location 2, prog A goes first * location 2, prog B goes first ... * location 50, prog A goes first * location 50, prog B goes first I think I have already explained why the current pMARS system is better than this. If you planned to run 200 battles instead, then consider how much better 200 battles with the pMARS system would be -- it would take the same amount of time as 200 battles with your method, but would give much more data. Or are you saying that there would only be one starting location and the battle would be run twice, once for each program going first? This is silly, because you are running just 2 battles when you could run 100. Or are you saying that it will run just like pMARS does now, except that the starting locations will be hardcoded (so that when you fight prog A against prog B, the result is always the same)? If so, you might want to have a look at the -f and -F switches on pMARS... -- Michael Constant (mconst@soda.csua.berkeley.edu) From: stu1136@discover.wright.edu (Eric Moyer) Subject: Re: Scoring Inaccuracies (Which Program Runs First?) Message-ID: Date: Mon, 14 Nov 1994 01:44:58 GMT In article <3a46u9$770@news.iastate.edu>, Rodney Schuler wrote: > >How about using pseudo-random numbers for choosing starting location? A >pseudo-random sequence (like Sobol's sequence) might give more uniform >results. Pseudo-random numbers have a much more uniform distribution >than random numbers and are gaurenteed not to repeat until the entire >space has been sampled. > >If anybody wishes, I can post some C code and a better explanation of >pseudo-random numbers. > >Rodney Schuler >Nuclear Engineering 186,282 miles per second >Iowa State University Its Not Just a Good Idea >rschuler@iastate.edu ITS THE LAW! I hope this isn't a troll, but if you have a true source for random numbers with a uniform distribution, you automatically have a[n absolutely] uniform distribution. There is nothing more uniform than a uniform distribution. A pseudo random number generator has a repetition period, since distributions are [usually] defined on a subset of the real or rational numbers, this means that there are some numbers that cannot be generated. Thus, the distribution is non-uniform. From: pk6811s@acad.drake.edu Subject: Rude Wind Date: 14 Nov 94 09:34:53 CST Message-ID: <1994Nov14.093453@acad.drake.edu> Here is the code for Rude Wind, a fairly effective one-shot scanner with a good imp-killing attack and paper. ;redcode-94 quiet ;name Rude Wind ;kill Rude Wind ;author P.Kline ;macro step equ 12 tstdjn dat 0,-1 pl1 spl #0 mov p2b,}scan ; anti-imp attack, part 1 mov >0,}5000 djn -2,#6 spl 1,>200 ; mov.i -1,#0 ; create 6 processes spl 1,>300 ; mov 6 ; 1st paper p1c mov -1356 mov p1b,p1s p1b dat <2667,<5334 for 20 dat 0,0 rof pl2 add #(2*step)+2691,scan spl #0 mov p2b,>scan ; anti-imp attack, part 2 mov >0,}1000 djn -2,#6 spl 1,<-100 ; mov.i -1,#0 ; create 6 processes spl 1,<-200 mov 6 ; 2nd paper p2c mov -1556 mov p2b,p2s p2b dat <2667,<5334 for 20 dat 0,0 rof inc dat 3*step,3*step bomb dat 0,step+step for 16 dat 0,0 rof next sub inc,scan ; scanner bombs one and scans two locations mov bomb,@scan ; in a four-instruction loop scan seq.x 7700+(10*step),@7700+(9*step) ; cmp a-b and b-a fields to find imps sne *scan,tstdjn ; ignore old-style djn-streams djn next,#7700/(step*3) mov p1b,-3500 ; end next+1 Paul Kline pk6811s@acad.drake.edu From: "Nathan T. Wild" Subject: CoreWars Wanted Date: Mon, 14 Nov 1994 14:00:06 -0600 Message-ID: I know there are several variation on the COREWAR game, I need one or more of the following: CoreWar for use under Linux (1.1.18 without X) CoreWar for use Under DOS or Windows (preferably DOS) RedCode Reference Book (preferably one which details differerences between different versions of the RedCode language) Please respond via email ASAP. Later: Nate... ------------------------------------------------------------------------ | Nathan T. Wild | Retail Systems | (204) 631-7378 VOX | | natewild@mbnet.mb.ca | Codville Distributors | (204) 694-2948 FAX | ------------------------------------------------------------------------ - A C++ Programmer Is Always Willing To Try New Things - From: PK6811S@ACAD.DRAKE.EDU Subject: The current Standard KotH hill: Date: 14 Nov 1994 14:37:38 -0600 Message-ID: <01HJH19W8JCY000F12@ACAD.DRAKE.EDU> /+|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+/ / * _________ . * . + . +__ __ * . * / /+ \========\ ____*_______ + ____* /==\* /==\_____ ._______+ ______ + / / . / \ .\/ /====\\===== \_/====\ \ \/\/ /\====\ \======\/=====/ / / \ \____( __ )| | \/\ ___/ + \ /. / __ \_| | \/\___ \ . / / * .\______ / \____/ |__|* \___ / . \__/\ / (____ /|__| /____ / / / . . + \/ + + . * \/ * .\/ + * \/ . + . \/ + / / * . . * . * . . * + / /|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-/ The current Standard KotH hill: # %W/ %L/ %T Name Author Score Age 1 42/ 26/ 32 Yop La Boum v2.1 P.E.M & E.C. 158 56 2 44/ 44/ 13 Dragon Spear c w blue 144 78 3 32/ 21/ 47 Sphinx v5.1 W. Mintardjo 143 12 4 32/ 21/ 47 Der Zweite Blitzkrieg Mike Nonemacher 142 60 5 43/ 45/ 12 Iron Gate 1.5 Wayne Sheppard 141 109 6 40/ 41/ 19 Vanity II Stefan Strack 140 100 7 29/ 19/ 51 CAPS KEY IS STUCK AGAIN Steven Morrell 140 66 8 39/ 40/ 21 Request v2.0 Brant D. Thomsen 138 79 9 26/ 15/ 59 ttti nandor sieben 136 82 10 28/ 19/ 53 The Plauge Anonymous 136 15 11 27/ 19/ 53 NC Killer Anonymous 135 16 12 37/ 39/ 23 Christopher Steven Morrell 135 52 13 34/ 33/ 32 Annihilator v2.1 Carlos Paredes 135 3 14 27/ 18/ 55 Blue Funk 88 Steven Morrell 135 25 15 27/ 19/ 54 Night Crawler Wayne Sheppard 134 5 16 28/ 24/ 47 B-Panama V.i Steven Morrell 132 10 17 37/ 41/ 22 Titled Steven Morrell 132 2 18 26/ 19/ 55 Imprimis 6 Anonymous 132 17 19 24/ 16/ 61 Peace Mr. Jones 132 1 20 34/ 38/ 28 Keystone t21 P.Kline 131 98 21 2/ 98/ 0 Status Check Anonymous 7 0 From: PK6811S@ACAD.DRAKE.EDU Subject: The current ICWS '94 Draft hill: Date: 14 Nov 1994 14:37:36 -0600 Message-ID: <01HJH173QOAQ002X75@ACAD.DRAKE.EDU> /+|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+/ / * _________ . * . + . +__ __ * . * / /+ \========\ ____*_______ + ____* /==\* /==\_____ ._______+ ______ + / / . / \ .\/ /====\\===== \_/====\ \ \/\/ /\====\ \======\/=====/ / / \ \____( __ )| | \/\ ___/ + \ /. / __ \_| | \/\___ \ . / / * .\______ / \____/ |__|* \___ / . \__/\ / (____ /|__| /____ / / / . . + \/ + + . * \/ * .\/ + * \/ . + . \/ + / / * . . * . * . . * + / /|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-/ The current ICWS '94 Draft hill: # %W/ %L/ %T Name Author Score Age 1 43/ 30/ 27 Torch t15 P.Kline 156 18 2 48/ 41/ 11 Agony II Stefan Strack 154 154 3 44/ 39/ 17 HeremScimitar A.Ivner,P.Kline 148 38 4 36/ 28/ 36 Rude Wind P.Kline 145 68 5 35/ 27/ 37 Blue Funk 3 Steven Morrell 143 219 6 38/ 34/ 28 Stimpy v2.0 Brant D. Thomsen 143 53 7 40/ 38/ 22 Leprechaun II Anders Ivner 142 12 8 28/ 15/ 57 B-Panama X Steven Morrell 141 160 9 40/ 40/ 20 Drowning III Mike Nonemacher 140 1 10 41/ 43/ 16 Iron Gate 1.5 Wayne Sheppard 139 508 11 38/ 38/ 24 SJ-4 J.Layland 138 220 12 32/ 27/ 41 Blue Funk Steven Morrell 138 531 13 29/ 22/ 49 Jet Black Reptile M R Bremer 137 5 14 27/ 20/ 53 Silk Warrior 1.4 J.Pohjalainen 133 161 15 25/ 17/ 58 Ryooki T.Hsu 133 6 16 23/ 14/ 63 Azuka T.Hsu 132 4 17 30/ 30/ 39 Killer Instinct II Anders Ivner 131 13 18 36/ 41/ 23 The Spanish Inquisition Steven Morrell 130 47 19 26/ 22/ 52 Aeka T.Hsu 130 174 20 26/ 23/ 51 Phoenix 1.2 J.Pohjalainen 130 111 21 2/ 98/ 0 Status Check Anonymous 7 0 From: PK6811S@ACAD.DRAKE.EDU Subject: The current Beginner hill: Date: 14 Nov 1994 14:37:32 -0600 Message-ID: <01HJH14RHRB6003706@ACAD.DRAKE.EDU> /+|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+/ / * _________ . * . + . +__ __ * . * / /+ \========\ ____*_______ + ____* /==\* /==\_____ ._______+ ______ + / / . / \ .\/ /====\\===== \_/====\ \ \/\/ /\====\ \======\/=====/ / / \ \____( __ )| | \/\ ___/ + \ /. / __ \_| | \/\___ \ . / / * .\______ / \____/ |__|* \___ / . \__/\ / (____ /|__| /____ / / / . . + \/ + + . * \/ * .\/ + * \/ . + . \/ + / / * . . * . * . . * + / /|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-/ The current Beginner hill: # %W/ %L/ %T Name Author Score Age 1 58/ 31/ 10 Samba2.2 Mr. Jones 185 21 2 57/ 33/ 10 Viewmaster4.0 Ryan Case 181 222 3 56/ 37/ 7 Ecstacy (XTC) Brant Thomsen 176 89 4 35/ 10/ 56 Peace Mr. Jones 160 5 5 39/ 27/ 34 Ox v1.0 Brian Zellner 150 18 6 28/ 12/ 60 Rabid Dwarfs v1.3 Brian Zellner 144 64 7 33/ 23/ 44 Slate, v0.3a Bharat Mediratta 143 143 8 40/ 37/ 23 Bloody Fang v2.1 Bharat Mediratta 142 9 9 37/ 36/ 27 AB Scanner 1.4a Chris Hodson 138 1 10 35/ 36/ 29 Green Knight v1.7 Brian Zellner 134 65 11 33/ 34/ 33 Count Zero #1 Marc Schefer 131 85 12 39/ 50/ 12 It Hari 127 206 13 26/ 25/ 49 Rubarbe et mort-vivant J.P.Laurin 126 92 14 24/ 23/ 53 War Machine v2.65 Matthias Wollnik 125 10 15 21/ 17/ 62 Paperous Mr. Jones 124 14 16 38/ 52/ 10 Cat v2.0 Tim Scheer 123 163 17 23/ 24/ 53 War Machine v2.6 Matthias Wollnik 123 11 18 25/ 30/ 45 strange carpet Erik Hughes 121 3 19 20/ 26/ 53 War Machine v2.5 Matthias Wollnik 114 12 20 18/ 28/ 54 Mostly Harmless Frank J. T. Wojcik 109 53 21 2/ 98/ 0 Status Check Anonymous 7 0 From: PK6811S@ACAD.DRAKE.EDU Subject: The current Beginner hill: Date: 14 Nov 1994 15:07:57 -0600 Message-ID: <01HJH2FUAWZ60035II@ACAD.DRAKE.EDU> /+|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+/ / * _________ . * . + . +__ __ * . * / /+ \========\ ____*_______ + ____* /==\* /==\_____ ._______+ ______ + / / . / \ .\/ /====\\===== \_/====\ \ \/\/ /\====\ \======\/=====/ / / \ \____( __ )| | \/\ ___/ + \ /. / __ \_| | \/\___ \ . / / * .\______ / \____/ |__|* \___ / . \__/\ / (____ /|__| /____ / / / . . + \/ + + . * \/ * .\/ + * \/ . + . \/ + / / * . . * . * . . * + / /|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-/ The current Beginner hill: # %W/ %L/ %T Name Author Score Age 1 58/ 31/ 10 Samba2.2 Mr. Jones 185 21 2 57/ 33/ 10 Viewmaster4.0 Ryan Case 181 222 3 56/ 37/ 7 Ecstacy (XTC) Brant Thomsen 176 89 4 35/ 10/ 56 Peace Mr. Jones 160 5 5 39/ 27/ 34 Ox v1.0 Brian Zellner 150 18 6 28/ 12/ 60 Rabid Dwarfs v1.3 Brian Zellner 144 64 7 33/ 23/ 44 Slate, v0.3a Bharat Mediratta 143 143 8 40/ 37/ 23 Bloody Fang v2.1 Bharat Mediratta 142 9 9 37/ 36/ 27 AB Scanner 1.4a Chris Hodson 138 1 10 35/ 36/ 29 Green Knight v1.7 Brian Zellner 134 65 11 33/ 34/ 33 Count Zero #1 Marc Schefer 131 85 12 39/ 50/ 12 It Hari 127 206 13 26/ 25/ 49 Rubarbe et mort-vivant J.P.Laurin 126 92 14 24/ 23/ 53 War Machine v2.65 Matthias Wollnik 125 10 15 21/ 17/ 62 Paperous Mr. Jones 124 14 16 38/ 52/ 10 Cat v2.0 Tim Scheer 123 163 17 23/ 24/ 53 War Machine v2.6 Matthias Wollnik 123 11 18 25/ 30/ 45 strange carpet Erik Hughes 121 3 19 20/ 26/ 53 War Machine v2.5 Matthias Wollnik 114 12 20 18/ 28/ 54 Mostly Harmless Frank J. T. Wojcik 109 53 21 2/ 98/ 0 Status Check Anonymous 7 0 From: PK6811S@ACAD.DRAKE.EDU Subject: The current Standard KotH hill: Date: 14 Nov 1994 15:17:18 -0600 Message-ID: <01HJH2TDHQJM003LD0@ACAD.DRAKE.EDU> /+|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+/ / * _________ . * . + . +__ __ * . * / /+ \========\ ____*_______ + ____* /==\* /==\_____ ._______+ ______ + / / . / \ .\/ /====\\===== \_/====\ \ \/\/ /\====\ \======\/=====/ / / \ \____( __ )| | \/\ ___/ + \ /. / __ \_| | \/\___ \ . / / * .\______ / \____/ |__|* \___ / . \__/\ / (____ /|__| /____ / / / . . + \/ + + . * \/ * .\/ + * \/ . + . \/ + / / * . . * . * . . * + / /|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-/ The current Standard KotH hill: # %W/ %L/ %T Name Author Score Age 1 42/ 26/ 32 Yop La Boum v2.1 P.E.M & E.C. 158 56 2 44/ 44/ 13 Dragon Spear c w blue 144 78 3 32/ 21/ 47 Sphinx v5.1 W. Mintardjo 143 12 4 32/ 21/ 47 Der Zweite Blitzkrieg Mike Nonemacher 142 60 5 43/ 45/ 12 Iron Gate 1.5 Wayne Sheppard 141 109 6 40/ 41/ 19 Vanity II Stefan Strack 140 100 7 29/ 19/ 51 CAPS KEY IS STUCK AGAIN Steven Morrell 140 66 8 39/ 40/ 21 Request v2.0 Brant D. Thomsen 138 79 9 26/ 15/ 59 ttti nandor sieben 136 82 10 28/ 19/ 53 The Plauge Anonymous 136 15 11 27/ 19/ 53 NC Killer Anonymous 135 16 12 37/ 39/ 23 Christopher Steven Morrell 135 52 13 34/ 33/ 32 Annihilator v2.1 Carlos Paredes 135 3 14 27/ 18/ 55 Blue Funk 88 Steven Morrell 135 25 15 27/ 19/ 54 Night Crawler Wayne Sheppard 134 5 16 28/ 24/ 47 B-Panama V.i Steven Morrell 132 10 17 37/ 41/ 22 Titled Steven Morrell 132 2 18 26/ 19/ 55 Imprimis 6 Anonymous 132 17 19 24/ 16/ 61 Peace Mr. Jones 132 1 20 34/ 38/ 28 Keystone t21 P.Kline 131 98 21 2/ 98/ 0 Status Check Anonymous 7 0 From: PK6811S@ACAD.DRAKE.EDU Subject: The current ICWS '94 Draft hill: Date: 14 Nov 1994 15:17:11 -0600 Message-ID: <01HJH2Q93PPU0031HQ@ACAD.DRAKE.EDU> /+|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+/ / * _________ . * . + . +__ __ * . * / /+ \========\ ____*_______ + ____* /==\* /==\_____ ._______+ ______ + / / . / \ .\/ /====\\===== \_/====\ \ \/\/ /\====\ \======\/=====/ / / \ \____( __ )| | \/\ ___/ + \ /. / __ \_| | \/\___ \ . / / * .\______ / \____/ |__|* \___ / . \__/\ / (____ /|__| /____ / / / . . + \/ + + . * \/ * .\/ + * \/ . + . \/ + / / * . . * . * . . * + / /|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-/ The current ICWS '94 Draft hill: # %W/ %L/ %T Name Author Score Age 1 43/ 30/ 27 Torch t15 P.Kline 156 18 2 48/ 41/ 11 Agony II Stefan Strack 154 154 3 44/ 39/ 17 HeremScimitar A.Ivner,P.Kline 148 38 4 36/ 28/ 36 Rude Wind P.Kline 145 68 5 35/ 27/ 37 Blue Funk 3 Steven Morrell 143 219 6 38/ 34/ 28 Stimpy v2.0 Brant D. Thomsen 143 53 7 40/ 38/ 22 Leprechaun II Anders Ivner 142 12 8 28/ 15/ 57 B-Panama X Steven Morrell 141 160 9 40/ 40/ 20 Drowning III Mike Nonemacher 140 1 10 41/ 43/ 16 Iron Gate 1.5 Wayne Sheppard 139 508 11 38/ 38/ 24 SJ-4 J.Layland 138 220 12 32/ 27/ 41 Blue Funk Steven Morrell 138 531 13 29/ 22/ 49 Jet Black Reptile M R Bremer 137 5 14 27/ 20/ 53 Silk Warrior 1.4 J.Pohjalainen 133 161 15 25/ 17/ 58 Ryooki T.Hsu 133 6 16 23/ 14/ 63 Azuka T.Hsu 132 4 17 30/ 30/ 39 Killer Instinct II Anders Ivner 131 13 18 36/ 41/ 23 The Spanish Inquisition Steven Morrell 130 47 19 26/ 22/ 52 Aeka T.Hsu 130 174 20 26/ 23/ 51 Phoenix 1.2 J.Pohjalainen 130 111 21 2/ 98/ 0 Status Check Anonymous 7 0 From: PK6811S@ACAD.DRAKE.EDU Subject: The current ICWS '94 Experimental (Big) hill: Date: 14 Nov 1994 15:52:47 -0600 Message-ID: <01HJH3YK9E6Q003K2T@ACAD.DRAKE.EDU> /+|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+/ / * _________ . * . + . +__ __ * . * / /+ \========\ ____*_______ + ____* /==\* /==\_____ ._______+ ______ + / / . / \ .\/ /====\\===== \_/====\ \ \/\/ /\====\ \======\/=====/ / / \ \____( __ )| | \/\ ___/ + \ /. / __ \_| | \/\___ \ . / / * .\______ / \____/ |__|* \___ / . \__/\ / (____ /|__| /____ / / / . . + \/ + + . * \/ * .\/ + * \/ . + . \/ + / / * . . * . * . . * + / /|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-/ The current ICWS '94 Experimental (Big) hill: # %W/ %L/ %T Name Author Score Age 1 46/ 32/ 22 ivscan6b J.Layland 161 35 2 47/ 36/ 17 Genocide 94x Mike Nonemacher 158 1 3 34/ 16/ 50 Big Phoenix 1.0 J.Pohjalainen 152 6 4 34/ 18/ 48 Aleph 1 Jay Han 150 33 5 44/ 38/ 19 Request-55440 Brant D. Thomsen 149 171 6 42/ 36/ 22 Stimpy v2.0 Brant D. Thomsen 148 26 7 46/ 44/ 10 Test Stefan Strack 147 7 8 43/ 41/ 16 Pyramid v5.3 Michael Constant 145 62 9 44/ 45/ 11 Rave B4.1 Stefan Strack 144 132 10 30/ 16/ 54 Big Silk Warrior 1.0 J.Pohjalainen 143 13 11 34/ 25/ 41 Variation G-1 Jay Han 142 135 12 38/ 39/ 23 Vanity IIx Stefan Strack 137 126 13 39/ 42/ 19 Fscan Jay Han 136 19 14 38/ 41/ 21 Aleph 0 Jay Han 136 34 15 30/ 27/ 43 Splash 1 Jay Han 133 136 16 29/ 26/ 45 Blue Funk Steven Morrell 133 25 17 29/ 25/ 47 NotSoBigImps James Layland 132 31 18 40/ 49/ 11 Squint Mike Nonemacher 131 109 19 31/ 31/ 38 Lucky 13 Stefan Strack 131 177 20 29/ 27/ 44 Der Zweite Blitzkrieg - 9 Mike Nonemacher 131 133 21 2/ 98/ 0 Status Check Anonymous 7 0 From: PK6811S@ACAD.DRAKE.EDU Subject: The current Experimental (Small) hill: Date: 14 Nov 1994 17:00:49 -0600 Message-ID: <01HJH6FVPGCY003CLB@ACAD.DRAKE.EDU> /+|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+/ / * _________ . * . + . +__ __ * . * / /+ \========\ ____*_______ + ____* /==\* /==\_____ ._______+ ______ + / / . / \ .\/ /====\\===== \_/====\ \ \/\/ /\====\ \======\/=====/ / / \ \____( __ )| | \/\ ___/ + \ /. / __ \_| | \/\___ \ . / / * .\______ / \____/ |__|* \___ / . \__/\ / (____ /|__| /____ / / / . . + \/ + + . * \/ * .\/ + * \/ . + . \/ + / / * . . * . * . . * + / /|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-/ The current Experimental (Small) hill: # %W/ %L/ %T Name Author Score Age 1 53/ 13/ 34 Lots of imps Wayne Sheppard 192 65 2 49/ 15/ 36 Paperous-II Mr. Jones 182 3 3 51/ 20/ 30 Killer Kevin Deitchman 182 28 4 50/ 24/ 26 Veeble Jr. T. H. Davies 175 64 5 43/ 38/ 19 HotSand 1.1 J. Pohjalainen 149 60 6 36/ 26/ 38 Circut 1.1 Brian Zellner 146 50 7 42/ 40/ 18 Freeze-x! Anonymous 144 52 8 45/ 46/ 9 Faster Hole Franz 143 5 9 45/ 47/ 9 Faster Hole v3 Franz 142 1 10 34/ 26/ 41 Decreaser Para v1.1 Franz 142 2 11 45/ 51/ 3 Alien 222 Franz 139 17 12 41/ 43/ 16 Triple Alien 22 v2 Franz 138 14 13 39/ 41/ 19 Sure Winner 1 Franz 138 13 14 41/ 46/ 13 Quattro Alien 22 v2 Franz 137 16 15 43/ 49/ 8 Waxed Paper Steven Morrell 137 63 16 39/ 44/ 18 Alien 22 the next generat Franz 134 20 17 41/ 48/ 11 Stone Jay Han 134 62 18 37/ 42/ 22 Lebia Maverick Paul Fenwick 132 45 19 37/ 43/ 19 Sure Winner 2 Franz 132 12 20 40/ 53/ 7 NiceTry 1.3a M R Bremer 127 54 21 2/ 98/ 0 Status Check Anonymous 7 0 From: jesensky@mix.cse.psu.edu (James J Jesensky) Subject: New type of tournament. (future hill?) Date: 15 Nov 1994 01:17:24 GMT Message-ID: <3a9274$c54@psuvax1.cse.psu.edu> Just an idea I came up with for a new type of Corewar tournament. Each ROUND, a random coresize and queue size are selected from a pre-determined range. Perhaps there is also a chance that read/write limits are enforced. A ROUND would consist of a few MATCHES. For example: 50 rounds, 10 matches per round /* total 500 matches */ coresize 4000-16000 queue size 8-8000 process limit per program. 25% chance of read/write limits per round. Limit=int(coresize*.05) However, both programs are RE-ASSEMBLED each round. The programs would use a #IF, #THEN, #ELSE type macro lang. with test similar to those allowed by the assert command. By using conditional assembly, the programmer could submit different code based on the mars parameters. Example ;redcode foo #IF THERE_ARE_LIMITS #THEN foo mov 0,1 ; imp #ELSEIF CORESIZE/4 == INT(CORESIZE/4) #THEN ;is core divisable be 4? foo add #4, x ; mod 4 dwarf mov x, @x jmp foo x dat #0, #0 #ELSE foo spl 0, #0 djn 0, In article , Eric Moyer wrote: >In article <3a46u9$770@news.iastate.edu>, >Rodney Schuler wrote: > >I hope this isn't a troll, but if you have a true source for random numbers >with a uniform distribution, you automatically have a[n absolutely] uniform >distribution. There is nothing more uniform than a uniform distribution. A >pseudo random number generator has a repetition period, since distributions >are [usually] defined on a subset of the real or rational numbers, this >means that there are some numbers that cannot be generated. Thus, the >distribution is non-uniform. OK, OK I was using inexact language. Of course you are correct for *real* numbers. However in this application we a generating integers in a certain range ie [0,(8000-100-SizeProgA-SizeProgB)]. I have not looked at the pMars source, but most programmers would implement this something like `int(rand()*Constant+1)'. This is likely to have repeating values before all of the possible starting locations are exhausted. With a well tailored pseudo random generator, the sequence will start to repeat only after all the possible starting locations are exhausted. -Rodney Schuler From: emoyer@cs.wright.edu (Eric Moyer) Subject: Newbie question Date: 15 Nov 1994 05:13:57 GMT Message-ID: <3a9g2l$qgd@valhalla.cs.wright.edu> How does one interpret the visual displays of core in programs like pmars (the one I am using). Both seem to assume that you will know that the blocks mean. (I assumed that I would too, until I tried to match the behavior of my program single stepping with that I interpreted from the arena view) (I had a modified imp running-- to make sure that the modifications were beneficial. (Since it's my first piece of Redcode, most of the mods haven't been, but, modifying an imp is a good first experimental project). Anyway, it seemed to stand still, while my carpet bombing opponent merrily filled up space with what I thought was my color. Nothing seemed to be happening, though this imp variant works fine in the debugger.) Thanks, --The Twilight Hunter P.S. I wasn't trying to use the imp as a warrior, just to check its behavior in combat situations. Also, I am coding- or at least trying to code- in ICWS'94.02. -- -------------------------------------__|__ ------------------------------------- "A wise man once said nothing" | Emoyer@valhalla.cs.wright.edu ---------------------------------------| --------------------------------------- From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 15 Nov 1994 10:06:57 GMT Message-ID: Archive-name: games/corewar-faq Last-modified: 1994/07/09 Version: 2.3.0 These are the Frequently Asked Questions (and answers) from the USENET newsgroup rec.games.corewar. This FAQ list is also available by anonymous FTP from rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.Z. TABLE OF CONTENTS Line ------------------------------------------------------------------------ 1. What is Core War? 69 2. Is it Core War or Core Wars? 82 3. Where can I find more information about Core War? 90 4. Core War has changed since Dewdney's articles. Where do I get 116 a copy of the current instruction set? 5. What is ICWS'94? Which simulators support ICWS'94? 135 6. What is the ICWS? 152 7. What is TCWN? 162 8. How do I join? 170 9. Are back issues of TCWNs available? 187 10. What is the EBS? 194 11. Where are the Core War archives? 208 12. Where can I find a Core War system for . . . ? 226 13. I do not have ftp. How do I get all of this great stuff? 275 14. I do not have access to Usenet. How do I post and receive news? 285 15. When is the next tournament? 303 16. What is KotH? How do I enter? 314 17. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 483 18. How does SLT (Skip if Less Than) work? 495 19. What does (expression or term of your choice) mean? 507 20. Other questions? 650 --------------------------------------------------------------------- Q 1: What is Core War? A 1: 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 posession 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. ---------------------------------------------------------------------- Q 2: Is it "Core War" or "Core Wars"? A 2: 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. ---------------------------------------------------------------------- Q 3: Where can I find more information about Core War? A 3: 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 two anthologies: Author: Dewdney, A. K. Title: The Armchair Universe: An Exploration of Computer Worlds Published: New York: W. H. Freeman (c) 1988 ISBN: 0-7167-1939-8 Library of Congress Call Number: QA76.6 .D517 1988 Author: Dewdney, A. K. Title: The Magic Machine: A Handbook of Computer Sorcery Published: New York: W. H. Freeman (c) 1990 ISBN: 0-7167-2125-2 (Hardcover), 0-7167-2144-9 (Paperback) Library of Congress Call Number: QA76.6 .D5173 1990 A.K. Dewdney's articles are still the most readable introduction to Core War, even though the Redcode dialect described in there is no longer current (see Q 4). --------------------------------------------------------------------- Q 4: Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? A 4: A draft of the official standard (ICWS'88) is available by anonymous FTP from the Core War archives (soda.berkeley.edu) as pub/corewar/documents/standards/redcode-icws-88.Z This document is formatted awkwardly and contains ambiguous statements. For a more approachable intro to Redcode, take a look at pub/corewar/documents/tutorial.1.Z tutorial.2.Z (See also Q11) Steven Morrell (morrell@math.utah.edu) is preparing a more practically oriented Redcode tutorial that discusses different warrior classes with lots of example code. Mail him for a preliminary version. Michael Constant (mconst@ soda.berkeley.edu) is reportedly working on a beginner's introduction. --------------------------------------------------------------------- Q 5: What is ICWS'94? Which simulators support ICWS'94? A 5: There is an ongoing discussion about future enhancements to the Redcode language. A proposed new standard, dubbed ICWS'94, is currently being evaluated. A major change is the addition of "instruction modifiers" that allow instructions to modify A-field, B-field or both. Also new is a post-increment indirect addressing mode and unrestricted opcode and addressing mode combination ("no illegal instructions"). ICWS'94 is backwards compatible; i.e. ICWS'88 warriors will run correctly on an ICWS'94 system. Take a look at the ICWS'94 draft for more information (soda.berkeley.edu pub/corewar/documents/icws94.0202.Z). You can try out the new standard by submitting warriors to the '94 hills of the KotH servers (see Q16). Two corewar systems currently support ICWS'94, pMARS (various platforms) and Redcoder (Mac), both available at soda (see Q12). --------------------------------------------------------------------- Q 6: What is the ICWS? A 6: 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). --------------------------------------------------------------------- Q 7: What is TCWN? A 7: Since March of 1987, "The Core War Newsletter" (TCWN) has been the official newsletter of the ICWS. It is published quarterly and recent issues are also available as Encapsulated PostScript on soda.berkeley.edu (see Q9). --------------------------------------------------------------------- Q 8: How do I join? A 8: For more information about joining the ICWS (which includes a subscription to TCWN), or to contribute an article, review, cartoon, letter, joke, rumor, etc. to TCWN, please contact: Jon Newman 13824 NE 87th Street Redmond, WA 98052-1959 email: jonn@microsoft.com (Note: Microsoft has NO affiliation with Core War. Jon Newman just happens to work there, and we want to keep it that way!) Current annual dues are $15.00 in US currency. ---------------------------------------------------------------------- Q 9: Are back issues of TCWN available? A 9: Recent issues can be found on soda.berkeley.edu (see Q11). Older issues (up to Winter 1991) are also available (see the next TCWN for details). --------------------------------------------------------------------- Q10: What is the EBS? A10: 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 are entered into the annual ICWS tournament. All EBS business is conducted in the rec.games.corewar 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 (see Q 5). ---------------------------------------------------------------------- Q11: Where is the Core War archive? A11: 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.149.19) in the /pub/corewar directories. Also, most of past rec.games.corewar postings (including Redcode source listings) are archived there. Jon Blow (blojo@soda.berkeley.edu) is the archive administrator. When uploading to /pub/corewar/incoming, ask Jon to move your upload to the appropriate directory and announce it on the net. Much of what is available on soda is also available on the German archive at iraun1.ira.uka.de (129.13.10.90) in the /pub/X11/corewars directory. This FAQ is automatically archived by news.answers. See the header for the current archive name and news.answers for how to get it. ---------------------------------------------------------------------- Q12: Where can I find a Core War system for . . . ? A12: Core War systems are available via anonymous ftp from soda.berkeley.edu in the pub/corewar/systems directory. Currently, there are UNIX, IBM PC-compatible, Macintosh, and Amiga Core War systems available there. It is a good idea to check pub/corewar/incoming for program updates first. CAUTION! There are many, many Core War systems available which are NOT ICWS'88 (or even ICWS'86) compatible available at various archive sites other than soda.berkeley.edu. Generally, the older the program - the less likely it will be ICWS compatible. Reviews of Core War systems would be greatly appreciated in the newsgroup and in the newsletter. Below is a not necessarily complete or up-to-date list of what's available at soda: MADgic41.lzh - corewar for the Amiga, v4.1 MAD4041.lzh - older version? MAD50B.lha - corewar for the Amiga, beta version 5.0 Redcoder-21.hqx - corewar for the Mac, supports ICWS'88 and '94 core-11.hqx - corewar for the Mac core-wars-simulator.hqx - same as core-11.hqx? corewar_unix_x11.tar.Z - corewar for UNIX/X-windows, ICWS'86 but not ICWS'88 compatible koth31.tar.Z - corewar for UNIX/X-windows. This program ran the former KotH server at intel.com koth.shar.Z - older version kothpc.zip - port of older version of KotH to the PC deluxe20c.tar.Z - corewar for UNIX (broken X-windows or curses) and PC mars.tar.Z - corewar for UNIX, likely not ICWS'88 compatible icons.zip - corewar icons for MS-Windows macrored.zip - a redcode macro-preprocessor (PC) c88v49.zip - PC corewar, textmode display mars88.zip - PC corewar, graphics mode display corwp302.zip - PC corewar, textmode display, slowish mercury2.zip - PC corewar written in assembly, fast! mtourn11.zip - tournament scheduler for mercury (req. 4DOS) pmars06s.zip - portable system, ICWS'88 and '94, runs on UNIX, PC, Mac, Amiga. C source archive pmars06s.tar.Z - same as above pmars06.zip - PC executables with graphics display, req 386+ macpmars02.sit.hqx - pMARS executable for Mac (port of version 0.2) ApMARS03.lha - pMARS executable for Amiga (port of version 0.3.1) wincor11.zip - MS-Windows system, shareware ($15) ---------------------------------------------------------------------- Q13: I do not have ftp. How do I get all of this great stuff? A13: There is an ftp email server at ftpmail@decwrl.dec.com. Send email with a subject and body text of "help" (without the quotes) for more information on its usage. If you don't have access to the net at all, send me a 3.5 '' diskette in a self-addressed disk mailer with postage and I will mail it back with an image of the Core War archives in PC format. My address is at the end of this post. ---------------------------------------------------------------------- Q14: I do not have access to Usenet. How do I post and receive news? A14: To receive rec.games.corewar articles by email, join the COREWAR-L list run on the Stormking.Com ListProcessor. To join, send: SUB COREWAR-L FirstName LastName to: LISTPROC@STORMKING.COM You can send mail to corewar-l@stormking.com to post even if you are not a member of the list. Responsible for the listserver is Scott J. Ellentuch (tuc@stormking.com). Another server that allows you to post (but not receive) articles is available. Email your post to rec-games-corewar@cs.utexas.edu and it will be automatically posted for you. ---------------------------------------------------------------------- Q15: When is the next tournament? A15: The ICWS holds an annual tournament. Traditionally, the deadline for entering is the 15th of December. The EBS usually holds a preliminary tournament around the 15th of November and sends the top finishers on to the ICWS tournament. Informal double-elimination tournaments are held frequently among readers of the newsgroup; watch there for announcements or contact me. ---------------------------------------------------------------------- Q16: What is KotH? How do I enter? A16: King Of The Hill (KotH) is an ongoing Core War tournament available to anyone with email. You enter by submitting via email a Redcode program with special comment lines. You will receive a reply indicating how well your program did against the current top twenty programs "on the hill". Your program will play 100 battles against each of the 20 other programs currently on the Hill. You receive 3 points for each win and 1 point for each tie. (The existing programs do not replay each other, but their previous battles are recalled.) All scores are updated to reflect your battles and all 21 programs are ranked from high to low. If you are number 21 you are pushed off the Hill, if you are higher than 21 someone else is pushed off. The original KotH was developed and run by William Shubert at Intel, and discontinued after almost three years of service. Currently, KotHs based on Bill's UNIX scripts but offering a wider variety of hills are are running at two sites: "koth@stormking.com" is maintained by Scott J. Ellentuch (tuc@stormking.com) and "pizza@ecst.csuchico.edu" by Thomas H. Davies (sd@ecst.csuchico.edu). Both KotHs provide very similar services and are therefore covered together. The principal difference is that "pizza" has a much faster internet connection than "stormking". 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 a line starting with ";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. (Also, see 5 below). 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 daemon 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. There are currently six separate hills you can select by starting your program with ;redcode, ;redcode-x, ;redcode-icws, ;redcode-b, ;redcode-94, or ;redcode-94x. More information on these hills is listed below. 3) Mail this file to "koth@stormking.com" or "pizza@ecst.csuchico.edu". "Pizza" requires a subject of "koth" (use the -s flag on most mailers). 4) Within a few minutes (or the next day for "stormking") you should get mail back telling you whether your program assembled correctly or not. If it did assemble correctly, sit back and wait; if not, make the change required and re-submit. 5) In an hour or so (or the next day for "stormking") you should get more mail telling you how your program performed against the current top 20 programs. If no news arrives during that time, don't worry; entries are put in a queue and run through the tournament one at a time. A backlog may develop. Be patient. If your program makes it onto the hill, you will get mail every time a new program makes it onto the hill. If this is too much mail, you can use ";redcode quiet" when you first mail in your program; then you will only get mail when you make it on the top 20 list or when you are knocked off. Using ";redcode verbose" will give you even more mail; here you get mail every time a new challenger arrives, even if they don't make it onto the top 20 list. Often programmers want to try out slight variations in their programs. If you already have a program named "foo V1.0" on the hill, adding the line ";kill foo" to a new program will automatically bump foo 1.0 off the hill. Just ";kill" will remove all of your programs when you submit the new one. The server kills programs by assigning an impossibly low score; it may therefore take another successful challenge before a killed program is actually removed from the hill. SAMPLE ENTRY: ;redcode ;name Dwarf ;author A. K. Dewdney ;strategy Throw DAT bombs around memory, hitting every 4th memory cell. ;strategy This program was presented in the first Corewar article. bomb DAT #0 dwarf ADD #4, bomb MOV bomb, @bomb JMP dwarf END dwarf ; Programs start at the first line unless ; an "END start" pseudo-op appears to indicate ; the first logical instruction. Also, nothing ; after the END instruction will be assembled. Here are the Specs for the various hills: ICWS'88 Standard Hill Specs: (Accessed with ";redcode", available at "stormking" and "pizza") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '88 ICWS Annual Tournament Hill Specs: (Accessed with ";redcode-icws", available at "stormking" only) coresize: 8192 instructions max. processes: 8000 per program duration: After 100,000 cycles, a tie is declared. max. entry length: 300 minimum distance: 300 instruction set: ICWS '88 ICWS'88 Experimental (Small) Hill Specs: (Accessed with ";redcode-x", available at "pizza" only) coresize: 4096 max. processes: 32 duration: after 65,536 cycles, a tie is declared. max. entry length: 64 minimum distance: 64 instruction set: ICWS '88 ICWS'94 Draft Hill Specs: (Accessed with ";redcode-94", available at "stormking" and "pizza") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '94 Draft ICWS'94 Beginner's Hill Specs: (Accessed with ";redcode-b", available at "pizza" only) coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '94 Draft ICWS'94 Experimental (Big) Hill Specs: (Accessed with ";redcode-94x", available at "stormking" and "pizza") coresize: 55440 max. processes: 10000 duration: after 500,000 cycles, a tie is declared. max. entry length: 200 minimum distance: 200 instruction set: ICWS '94 Draft If you just want to get a status report without actually challenging the hills, send email with ";status" as the message body (and don't forget "Subject: koth" for "pizza"). If you send mail to "pizza" with "Subject: koth help" you will receive instructions that may be more up to date than those contained in this document. All hills run portable MARS (pMARS) version 0.6, a platform-independent corewar system available at soda (see Q12). The '94 and '94x hills allow three experimental opcodes and addressing modes currently not covered in the ICWS'94 draft document: SEQ - Skip if EQual (synonym for CMP) SNE - Skip if Not Equal NOP - (No OPeration) * - indirect using A-field as pointer { - predecrement indirect using A-field } - postincrement indirect using A-field ---------------------------------------------------------------------- Q17: Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? A17: Core is initialized to DAT 0, 0. This is an "illegal" instruction under ICWS'88 rules and strictly compliant assemblers (such as KotH or pmars -8) will not let you write a DAT 0, 0 instruction - only DAT #0, #0. So this begs the question, how to compare something to see if it is empty core. The answer is, most likely the instruction before your first instruction and the instruction after your last instruction are both DAT 0, 0. You can use them, or any other likely unmodified instructions, for comparison. Note that under ICWS'94, DAT 0, 0 is a legal instruction. ---------------------------------------------------------------------- Q18: How does SLT (Skip if Less Than) work? A18: SLT gives some people trouble because of the way modular arithmetic works. It is important to note that all negative numbers are converted to positive numbers before a battles begins. Example: (-1) becomes (M - 1) where M is the memory size. Once you realize that all numbers are treated as positive, it is clear what is meant by "less than". It should also be clear that no number is less than zero. ---------------------------------------------------------------------- Q19: What does (expression or term of your choice) mean? A19: Here is a selected glossary of terms. If you have a definition and/or term you wish to see here, please send it to me. (References to an X-like program mean that the term X is derived from the specific program X and has become a generic term). Bootstrapping - Strategy of copying the active portion of the program away from the initial location, leaving a decoy behind and making the relocated program as small as possible. B-Scanners - Scanners which only recognize non-zero B-fields. example add #10,scan scan jmz example,10 C - Measure of speed, equal to one location per cycle. Speed of light. CMP-Scanner - A Scanner which uses a CMP instruction to look for opponents. example add step,scan scan cmp 10,30 jmp attack jmp example step dat #20,#20 Color - Property of bombs making them visible to scanners, causing them to attack useless locations, thus slowing them down. example dat #100 Core-Clear - code that sequentially overwrites core with DAT instructions; usually the last part of a program. Decoys - Bogus or unused instructions meant to slow down Scanners. Typically, DATs with non-zero B-fields. DJN-Stream (also DJN-Train) - Using a DJN command to rapidly decrement core locations. example . . . . . . djn example,<4000 Dwarf - the prototypical small bomber. Gate-busting - (also gate-crashing) technique to "interweave" a decrement-resistant imp-spiral (e.g. MOV 0, 2668) with a standard one to overrun imp-gates. Hybrids - warriors that combine two or more of the basic strategies, either in sequence (e.g. stone->paper) or in parallel (e.g. imp/stone). Imp - Program which only uses the MOV instruction. example MOV 0, 1 or example MOV 0, 2 MOV 0, 2 Imp-Gate - A location in core which is bombed or decremented continuously so that an Imp can not pass. Also used to describe the program-code which maintains the gate. example ... ... SPL 0, James J Jesensky wrote: >Just an idea I came up with for a new type of Corewar tournament. >Each ROUND, a random coresize and queue size are selected from a >pre-determined range. Perhaps there is also a chance that read/write >limits are enforced. A ROUND would consist of a few MATCHES. For example: This has been suggested before, but I don't think it's ever actually been implemented. With the exception of the read/write limits (please, *please*, let's not get into another discussion about them), I think that it's a great idea. I also don't remember hearing any opposition to this idea the first time it was proposed... just that nothing ever actually happened (other than my little mini-tournament, which (if nothing else) proved that a variable-coresize competition can work). Here is a slightly different proposal for variable-coresize battles, which I think is a little better: A variable-coresize battle would be run just like a fixed- coresize battle, except that each round a new coresize would be randomly chosen from a given range. For statistical accuracy, variable-coresize battles should probably be run with at least 200 or 300 rounds. Perhaps pmars could be modified to accept a switch like "-s 200-10000". That wouldn't be very hard (or would it?)... then we could have a var- iable-coresize hill, which would be pretty neat. There were certainly some neat program ideas in my mini-tournament, and we could probably expect to see more in an actual hill. Any other opinions? -- Michael Constant (mconst@soda.csua.berkeley.edu) From: sieben@imap1.asu.edu Subject: Re: New type of tournament. (future hill?) Date: 16 Nov 1994 06:45:21 GMT Message-ID: <3ac9q1$9gr@news.asu.edu> James J Jesensky (jesensky@mix.cse.psu.edu) wrote: : Just an idea I came up with for a new type of Corewar tournament. : Each ROUND, a random coresize and queue size are selected from a : pre-determined range. Perhaps there is also a chance that read/write : limits are enforced. A ROUND would consist of a few MATCHES. For example: : 50 rounds, 10 matches per round /* total 500 matches */ : coresize 4000-16000 : queue size 8-8000 process limit per program. : 25% chance of read/write limits per round. Limit=int(coresize*.05) : However, both programs are RE-ASSEMBLED each round. The programs would : use a #IF, #THEN, #ELSE type macro lang. with test similar to those : allowed by the assert command. By using conditional assembly, the : programmer could submit different code based on the mars parameters. : Example : ;redcode foo : #IF THERE_ARE_LIMITS #THEN : foo mov 0,1 ; imp : #ELSEIF CORESIZE/4 == INT(CORESIZE/4) #THEN ;is core divisable be 4? : foo add #4, x ; mod 4 dwarf : mov x, @x : jmp foo : x dat #0, #0 : #ELSE : foo spl 0, #0 : djn 0, >P-Robots has much more potential the CROBOTS and derivitives. While >C/C++ >robots still uses the same world, P-ROBOTS allows things like bombs, >cloaking, different engines, different arnaments, healing. It also has a >neat concepts of different robot configuration, where you can put weights on >each of these properties out of a certain number of points. Where could I find a copy of P-ROBOTS? Also is there a copy for DOS or Windows? From: guthrie@miu.edu Subject: CRobots: Summary? Date: Wed, 16 Nov 94 11:45:22 CDT Message-ID: <3adgjm$he2@news.iastate.edu> I wandered into this CRobots (C++Robots, etc..) midstream from a pointer in another group. Could someone please summarize the availablity of code, info, docs, etc. on this topic; either here or offline. Ah, the memory-less nature of newsgroups... Thanks. From: bporter@alfo06.attmail.com Subject: Re: CoreWars Wanted Message-ID: Date: Wed, 16 Nov 1994 15:55:03 GMT In article , writes: > Path: ncrcae!ncrhub2!ncrgw2.ncr.com!uunet!bloom-beacon.mit.edu!news.bu.e du!olivea!news.hal.COM!decwrl!tribune.usask.ca!canopus.cc.umanitob a.ca!access.mbnet.mb.ca!natewild > From: "Nathan T. Wild" > Newsgroups: rec.games.corewar > Subject: CoreWars Wanted > Date: Mon, 14 Nov 1994 14:00:06 -0600 > Organization: The University of Manitoba > Lines: 20 > Message-ID: > I know there are several variation on the COREWAR game, I need one or > more of the following: > > CoreWar for use under Linux (1.1.18 without X) > CoreWar for use Under DOS or Windows (preferably DOS) > RedCode Reference Book (preferably one which details differerences > between different versions of the RedCode language) > Please respond via email ASAP. > > > Later: > Nate... > > ------------------ - > I'd like to get a copy for DOS or Windows, also. Any doc. would be greatly appreciated. Bill Porter From: georgel@gas.uug.arizona.edu Subject: Make corewar programs do something Date: 16 Nov 1994 20:09:09 GMT Message-ID: <3adot5$1uf@news.CCIT.Arizona.EDU> When I read the original articles about corewar, it is talking about the winner getting control over the memory and the computers recources. Well there aren't any. How about add an instruction at random ito the playng field and if a program would execute the instruction it won. The instruction would be NOP, or unexecutable, program would die, anywhere else. This would make the programs smarter then just to blindly bomb the core. if you bomb into the instruction, how are you gonna find it. A program could set false winning instructions to confuse or kill the other program. The coresize would probably have to be about the size of the big hill. The scoring could be: Program found winning instruction - 6 points, program killed opponent - 3 points, programs tied - 1 point. This way you don't have to kill opponent to get the maximum points, but it would be advisable, cause than he cannot find the winning instruction first. Comments? George ------------------------------------------------------------------------------ ___ | George Lebl FRANZ / | \ | georgel@gas.uug.arizona.edu | | | /|\ | | Sex Pistols RULE! |-O-| \/_|_\/ | The force is with you | | From: jesensky@mix.cse.psu.edu (James J Jesensky) Subject: Re: New type of tournament. (future hill?) Date: 16 Nov 1994 22:21:56 GMT Message-ID: <3ae0m5$rfk@psuvax1.cse.psu.edu> In article <3abiri$3k3@agate.berkeley.edu> mconst@soda.CSUA.Berkeley.EDU (Michael Constant) writes: >James J Jesensky wrote: >>[deleted] >[stuff deleted] >Here is a slightly different proposal for variable-coresize battles, >which I think is a little better: [As opposed to using #if's and #then's for condition assembly] > > A variable-coresize battle would be run just like a fixed- > coresize battle, except that each round a new coresize would > be randomly chosen from a given range. > This would work too given the following: *Max cycles are large enough to avoid an increase in ties for large coresizes. *That ALL arithmetic is still mod coresize. By this I mean I would want to code: cs dat #-1, #-1 ; Coresize-1 jim From: jesensky@mix.cse.psu.edu (James J Jesensky) Subject: My $.02 on 94 std. Date: 16 Nov 1994 23:40:57 GMT Message-ID: <3ae5a9$fc@psuvax1.cse.psu.edu> Still needed in standard: * Opcodes (with modifiers/addressing modes) should be stored as numbers. Core locations would be a tuple (Opcode,A-field, B-field) of 16 bit integers. A-fields and B-fields are 16 bit integers. Opcode would be coded perhaps as a 16 bit integer xxIIIIIMMMAAABBB, where x is don't care, IIIII is a 5 bit instruction, MMM is a 3 bit modifier, AAA and BBB are the A/B-fields addressing modes. Eventhough A-fields and B-fields are 16 bit, all addressing is still mod coresize. You can now ADD.I two instuctions, etc. May have to add a couple extra modifiers. * A register! A register! My Kingdom for a register! How about 2 registers %s and %r. Both %s and %r are general purpose, although %s is initialize to 0+max_prog_size in case you want to use it as a stack pointer. (In which case it would move down memory in your programs unused space). * Give me more instrctions or give me death! What about: shl shift A left B bits (no need for arithmetic vs logical shifting since numbers are unsigned) shr shift A right B bits rol rotate A to the right B bits ror rotate A to the left B bits and bit wise and of A and B ior bit wise ior of A and B xor bit wise xor of A and B not bit wise not of A neg A is assigned CORESIZE-A sXX Skip if A is XX then B. XX=lt|gt|eq|ne|ge|le etc...I know, what good would are all these instructions? I don't know yet. Who would of thought an imp-based program would be koth two years ago? * MULTITASKING. Creating new processes is probably the one thing that makes Corewar more interesting than any other feature. Let's expand on it then! spl create new process at A spc create child at A. Parents and childred share their time slice. spt create thread at A. Threads cannot create other processes. If a thread executes a spX, the A and B things are evaluated but no new process is created. * MARS system services. Why can't MARS provide some basic services. Create a new instruction mss (MARS system service) where mss A,B would invoke service #A with parameter/return loction B. Say services 0-15 are fixed and 16-31 are 'implementation defined'. Some examples: mss 0, X Return current number of my processes executing in X mss 1, X Return Coresize in X mss 2, X Return random integer between 0 and X in X mss 3, X Do not execute next cycle etc... Don't say this too radical--of course it is! But I hope there is at least a few items mentioned above that get discussed for possible inclusion in the 94 std. BTW: Is there a need for a Redcode II and MARS II? Possibly modeled (stolen) from real computers specs. Call it Corewar II. This would only be played by the true bit heads. Maybe simulate a LAN of Amigas? Jim From: jesensky@mix.cse.psu.edu (James J Jesensky) Subject: Let's run all the programs at once Date: 17 Nov 1994 23:19:35 GMT Message-ID: <3agoe7$ad5@psuvax1.cse.psu.edu> Here's an idea for a future hill or tournament. Run all the programs together instead of two at a time. I think in this type of run-time enviroment will require new programming strategies to be successful. Below are the considerations: * It should be rather simple to modify MARS code to handle >2 programs in the core. * Coresize. Two programs share 8000 instructions. Should 20 programs share 80000? 100000? * Max cycles. I think 500000 should do it. * Max processes. I don't think it should be so huge that programs just spend all day spl'ing. Maybe 256? How stressful would this be on a system? koth=20 progs * 80000 cycles * 2 progs/cycle * 200 matches = 640,000,000 new=500000 cycles * 20 progs/cycle * 100 match = 1,000,000,000 So 100 matches is almost twice a koth challenge. * Scoring. Open for ideas. Would be nice to award programs for offense instead of just for staying alive. Jim From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) Subject: Re: Let's run all the programs at once Date: 18 Nov 1994 02:10:30 GMT Message-ID: <3ah2em$r39@agate.berkeley.edu> James J Jesensky wrote: >Here's an idea for a future hill or tournament. Run all the programs >together instead of two at a time. I think in this type of run-time >enviroment will require new programming strategies to be successful. Neat idea, although I'm not sure it would work: I think that it would make offensive strategies much harder to implement, and thus it would revolve around defensive strategies, which tend to be less interesting. For example, a quick-scanner could never exist in such an environment, but a big, slow imp-spiral would survive quite nicely. Even a normal scanner would be at a significant disadvantage, because it is only fast enough to kill one opponent. The programs which would succeed would be those which can kill passively rather than actively -- i.e. paper and imps. Those two program types will do equally well in a one-on-one match and in a multi-program match... but all the other program types I know of would be at a significant disadvantage. -- Michael Constant (mconst@soda.csua.berkeley.edu) From: "Nathan T. Wild" Subject: C++Robots?? Binaries? Date: Fri, 18 Nov 1994 09:29:31 -0600 Message-ID: Where can I get executables or source for the following programs that will run under DOS, Windows or Linux... C++Robots CRobots CoreWars (For Linux with or without X) PRobots I am compiling a web page for games of this nature and I would like to set up links to these files. I also want to play some of these games. I have an old version of CRobots and a nifty game called PCrobots (both DOS) I would like to try C++Robots... Later: Nate... ------------------------------------------------------------------------ | Nathan T. Wild | Retail Systems | (204) 631-7378 VOX | | natewild@mbnet.mb.ca | Codville Distributors | (204) 694-2948 FAX | ------------------------------------------------------------------------ - A C++ Programmer Is Always Willing To Try New Things - From: doctorx@rain.org Subject: Anyone using the orig. Corewars? Date: 18 Nov 1994 23:55:55 -0800 Message-ID: <3akb2b$77g@coyote.rain.org> Is anyone writing code for the original Corewars by Dewdney? I am writing a few warriors and would like to try them against other warriors. Post them here (Redcode assembly -- not compiled) and I'll post mine too. Thx! O=-- -=O=- --=O | doctorx@rain.org | O=-- -=O=- --=O From: ruhl@du.edu (Robert A. Uhl) Subject: Redcode Help Message-ID: Date: Sun, 20 Nov 1994 04:14:26 GMT I've DL'ed several of the docs on Redcode, incl. the ICWS'94 standard and Tutorials one & two. However, I still need a good, _in-depth_, guide to Redcode. Does anyone have any pointers to info? Please reply via email, as this site seems to be having difficulty recv'ing news. TIA. -- -------------------------------------- | Bob Uhl | Spectre | | U of D | Baron Robert von Raetzin | -------------------------------------- From: han@imag.fr (Jay "Thierry" Han) Subject: Re: Let's run all the programs at once Date: 21 Nov 1994 12:02:00 GMT Message-ID: In article <3ah2em$r39@agate.berkeley.edu> mconst@soda.CSUA.Berkeley.EDU (Michael Constant) writes: > From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) > Subject: Re: Let's run all the programs at once > Date: 18 Nov 1994 02:10:30 PST-8 > > James J Jesensky wrote: > >Here's an idea for a future hill or tournament. Run all the programs > >together instead of two at a time. I think in this type of run-time > >enviroment will require new programming strategies to be successful. > > Neat idea, although I'm not sure it would work: I think that it would > make offensive strategies much harder to implement, and thus it would > revolve around defensive strategies, which tend to be less interesting. > For example, a quick-scanner could never exist in such an environment, > but a big, slow imp-spiral would survive quite nicely. Even a normal > scanner would be at a significant disadvantage, because it is only fast > enough to kill one opponent. The programs which would succeed would > be those which can kill passively rather than actively -- i.e. paper > and imps. Those two program types will do equally well in a one-on-one > match and in a multi-program match... but all the other program types > I know of would be at a significant disadvantage. I'm not sure. A fast stone at start-up may do a lot of damage. On the other hand, the spiral now is attacked by 19 gates, i.e. for every cycle in the spiral 19 instructions are executed somewhere else. Same thing for paper. Actually, I think there might be a new equilibrium. What would happen, for instance, if out of the 20 programs 10 are papers, 9 are stone/imps and there's one vamp? The stones would probably kill each other, the papers would swamp each other, and the vamp would go on freezing everybody. What's interesting and also confusing is that your program's score would depend a lot on the proportions of program types currently on the hill. Making an all-round good program would be even harder than now. -=< Jay "Thierry" Han >=- han@imag.fr Bull-IMAG/Systemes. 2, av. Vignate. ZI Mayencin II, 38610 Gieres. Tel: +33 76.63.48.42. Fax: 76.54.76.15. Perso: 61, rue Thiers. 38000 Grenoble. 76.46.11.26. From: sieben@imap1.asu.edu Subject: Re: Let's run all the programs at once Date: 21 Nov 1994 18:57:24 GMT Message-ID: <3aqqik$7gk@news.asu.edu> James J Jesensky (jesensky@mix.cse.psu.edu) wrote: : Here's an idea for a future hill or tournament. Run all the programs : together instead of two at a time. I think in this type of run-time : enviroment will require new programming strategies to be successful. : Below are the considerations: : * It should be rather simple to modify MARS code to handle >2 programs : in the core. It could be little bit of work to change pMars, it wasn't considered at all during the construction of the data structure to make this change easy. Albert, are you listening? Would it slow down things? Nandor. From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) Subject: Re: Let's run all the programs at once Date: 21 Nov 1994 20:26:09 GMT Message-ID: <3aqvp1$4ad@agate.berkeley.edu> Jay "Thierry" Han wrote: > mconst@soda.CSUA.Berkeley.EDU (Michael Constant) writes: >> James J Jesensky wrote: >> >Here's an idea for a future hill or tournament. Run all the programs >> >together instead of two at a time. I think in this type of run-time >> >enviroment will require new programming strategies to be successful. >> >> [ mconst saying "it won't work" ] > >I'm not sure. A fast stone at start-up may do a lot of damage. A fast stone certainly would do a lot of damage... but that doesn't mean that the stone will score well! The stone will quickly be killed by something, since it has no defenses at all and it is being attacked by 19 other programs. The poor stone will have sacrificed itself for the greater good, but that's not the point of corewar ;-) For a specific example, take Torch. This is a great program in the standard corewar setting -- it manages to stun its opponent very quickly, and then mop it up with a coreclear. However, Tocrh would get torched (npi) in a multi-program battle, because it will only be able to stun so many programs before something hits it. Now, you may be thinking, "good, we'll have to have a change of strategy." Certainly, that would be a nice thing, but I don't think that such a radical shift towards defensive programs would be good. I hold by my original statment that the best-scoring programs (by far) will be paper and imps. To do well in the crowded arena, a program will have to survive the attacks of 19 other programs... quick offensive programs just won't work, since they'll have to kill 19 programs before getting hit by the crossfire. The top programs would be very fast papers, which could survive several hits of just about anything before dying. However, I'm not averse to trying a multi-program hill/tournament. It would certainly be a change from the regular one-on-one battles... but I think it would quickly degenerate into rather boring programs. -- Michael Constant (mconst@soda.csua.berkeley.edu) From: napierjj@ucunix.san.uc.edu (Jeffrey Joseph Napier) Subject: FAQ? Date: 21 Nov 1994 21:24:40 -0500 Message-ID: <3arkp8$89r@ucunix.san.uc.edu> s there a FAQ available.Thanks. From: PK6811S@ACAD.DRAKE.EDU Subject: The current Beginner hill: Date: 22 Nov 1994 08:29:27 -0600 Message-ID: <01HJRUWRPR5E000ZOG@ACAD.DRAKE.EDU> /+|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+/ / * _________ . * . + . +__ __ * . * / /+ \========\ ____*_______ + ____* /==\* /==\_____ ._______+ ______ + / / . / \ .\/ /====\\===== \_/====\ \ \/\/ /\====\ \======\/=====/ / / \ \____( __ )| | \/\ ___/ + \ /. / __ \_| | \/\___ \ . / / * .\______ / \____/ |__|* \___ / . \__/\ / (____ /|__| /____ / / / . . + \/ + + . * \/ * .\/ + * \/ . + . \/ + / / * . . * . * . . * + / /|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-/ The current Beginner hill: # %W/ %L/ %T Name Author Score Age 1 58/ 31/ 10 Samba2.2 Mr. Jones 185 21 2 57/ 33/ 10 Viewmaster4.0 Ryan Case 181 222 3 56/ 37/ 7 Ecstacy (XTC) Brant Thomsen 176 89 4 35/ 10/ 56 Peace Mr. Jones 160 5 5 39/ 27/ 34 Ox v1.0 Brian Zellner 150 18 6 28/ 12/ 60 Rabid Dwarfs v1.3 Brian Zellner 144 64 7 33/ 23/ 44 Slate, v0.3a Bharat Mediratta 143 143 8 40/ 37/ 23 Bloody Fang v2.1 Bharat Mediratta 142 9 9 37/ 36/ 27 AB Scanner 1.4a Chris Hodson 138 1 10 35/ 36/ 29 Green Knight v1.7 Brian Zellner 134 65 11 33/ 34/ 33 Count Zero #1 Marc Schefer 131 85 12 39/ 50/ 12 It Hari 127 206 13 26/ 25/ 49 Rubarbe et mort-vivant J.P.Laurin 126 92 14 24/ 23/ 53 War Machine v2.65 Matthias Wollnik 125 10 15 21/ 17/ 62 Paperous Mr. Jones 124 14 16 38/ 52/ 10 Cat v2.0 Tim Scheer 123 163 17 23/ 24/ 53 War Machine v2.6 Matthias Wollnik 123 11 18 25/ 30/ 45 strange carpet Erik Hughes 121 3 19 20/ 26/ 53 War Machine v2.5 Matthias Wollnik 114 12 20 18/ 28/ 54 Mostly Harmless Frank J. T. Wojcik 109 53 21 2/ 98/ 0 Status Check Anonymous 6 0 From: PK6811S@ACAD.DRAKE.EDU Subject: The current ICWS '94 Draft hill: Date: 22 Nov 1994 08:31:22 -0600 Message-ID: <01HJRUZ6K5AQ000WXX@ACAD.DRAKE.EDU> /+|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+/ / * _________ . * . + . +__ __ * . * / /+ \========\ ____*_______ + ____* /==\* /==\_____ ._______+ ______ + / / . / \ .\/ /====\\===== \_/====\ \ \/\/ /\====\ \======\/=====/ / / \ \____( __ )| | \/\ ___/ + \ /. / __ \_| | \/\___ \ . / / * .\______ / \____/ |__|* \___ / . \__/\ / (____ /|__| /____ / / / . . + \/ + + . * \/ * .\/ + * \/ . + . \/ + / / * . . * . * . . * + / /|-+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-|+--+--+--+|-+--+--+--|--+--+--+-/ The current ICWS '94 Draft hill: # %W/ %L/ %T Name Author Score Age 1 50/ 39/ 11 Taking names P.Kline 162 1 2 45/ 31/ 24 Torch t15 P.Kline 158 33 3 45/ 35/ 20 Stimpy 3.0 Brant D. Thomsen 154 5 4 45/ 38/ 17 HeremScimitar A.Ivner,P.Kline 152 53 5 47/ 43/ 10 Agony II Stefan Strack 151 169 6 39/ 28/ 33 Blue Funk 3 Steven Morrell 149 234 7 41/ 39/ 20 SJ-4 J.Layland 144 235 8 31/ 19/ 50 B-Panama X Steven Morrell 143 175 9 35/ 28/ 37 Blue Funk Steven Morrell 142 546 10 40/ 39/ 21 Leprechaun II Anders Ivner 141 27 11 37/ 34/ 29 Rude Wind P.Kline 140 83 12 42/ 44/ 14 Iron Gate 1.5 Wayne Sheppard 140 523 13 40/ 42/ 18 Drowning III Mike Nonemacher 138 16 14 30/ 25/ 46 Aeka T.Hsu 135 189 15 38/ 43/ 19 The Spanish Inquisition Steven Morrell 134 62 16 33/ 35/ 32 Killer Instinct II Anders Ivner 132 28 17 27/ 22/ 52 Ryooki T.Hsu 131 21 18 28/ 25/ 47 Silk Warrior 1.4 J.Pohjalainen 131 176 19 28/ 30/ 42 Jet Black Reptile M R Bremer 127 20 20 9/ 4/ 2 Test Brant D. Thomsen 28 6 21 2/ 98/ 0 Status Check Anonymous 6 0 From: georgel@gas.uug.arizona.edu Subject: IMP stumper made easy Date: 22 Nov 1994 17:02:52 GMT Message-ID: <3at87s$5to@news.CCIT.Arizona.EDU> You can add an IMP stomper to your programs by decreasing b filed at a location a few about 5 or 10 instructions before the program, by adding <-? to b filed of jmp instructions or using pointers that are decreased before the code. eg. dwarf that would lose or tie with imps: MOV bomb,-1 SUB #4,-1 JMP -2 now this will always kill imps (though do the same thing) MOV bomb,<-9 SUB #3,<-10 JMP -2,<-11 See the difference? Even though b filed in jump is not used, it is still evaluated George ------------------------------------------------------------------------------ ___ | George Lebl FRANZ / | \ | georgel@gas.uug.arizona.edu | | | /|\ | | Sex Pistols RULE! |-O-| \/_|_\/ | The force is with you | | From: georgel@gas.uug.arizona.edu Subject: Easy carpet bomber Date: 22 Nov 1994 17:10:27 GMT Message-ID: <3at8m3$61s@news.CCIT.Arizona.EDU> To make a carpet bomber, all you need is an offset that will bomb instructions, not linearly, but rather everywhere first. Any dwarf can do this, to find out the offset, take the usual offset number and multiply it by a number that is not a dividend of coresize, (n/CORESIZE)<>INT(n/CORESIZE) e.g. 4 * 11 every fourth location will be bombed, these are bombed at intervals of 11. MOV bomb,-1 ADD #4*11,-1 JMP -2 The newsgroup should include more info like this or better, since I had to find this for myself and I guess all new guys should know it George ------------------------------------------------------------------------------ ___ | George Lebl FRANZ / | \ | georgel@gas.uug.arizona.edu | | | /|\ | | Sex Pistols RULE! |-O-| \/_|_\/ | The force is with you | | From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) Subject: Re: IMP stumper made easy Date: 22 Nov 1994 20:27:09 GMT Message-ID: <3atk6t$eqa@agate.berkeley.edu> wrote: >You can add an IMP stomper to your programs by decreasing b filed at a >location a few about 5 or 10 instructions before the program, by adding ><-? to b filed of jmp instructions or using pointers that are decreased >before the code. Congratulations, you have discovered the imp-gate :-) This is one of the most common ways of dealing with imps right now. Briefly, here are a few other ways of dealing with imps: - "anti-imp paper": use a replicator that will try to kill imps instead of just tying them. This works pretty well. - "anti-imp scanner: a scanner that's set up to notice and kill imps -- a scanner which is not tailored to beat imps will usually not be able to stun them. Very effective, as long as the scanner still works against *other* programs... - "quick-scanner": a program which actively scans for and kills imps (or any other large program) before they can start up -- very effective if you can get it fast enough -- Michael Constant (mconst@soda.csua.berkeley.edu) From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) Subject: Re: Easy carpet bomber Date: 22 Nov 1994 20:41:24 GMT Message-ID: <3atl1k$f2o@agate.berkeley.edu> wrote: > To make a carpet bomber, all you need is an offset that will bomb >instructions, not linearly, but rather everywhere first. This is the beginning of the theory of optimal bombing/scanning constants, called "optima numbers" for short. Your dwarf can, in fact, be even more efficient than you have made it... if you start using really large numbers you can increase the efficiency slightly. There is a program to calculate these numbers: Corestep, by Jay Han (available at ftp.csua.berkeley.edu, as /pub/corewar/misc/corestep.c, or something like that). >The newsgroup should include more info like this or better, since I had >to find this for myself and I guess all new guys should know it Check out the FAQ ;-) -- Michael Constant (mconst@soda.csua.berkeley.edu) From: stu1136@discover.wright.edu (Eric Moyer) Subject: Re: Let's run all the programs at once Message-ID: Date: Wed, 23 Nov 1994 01:40:20 GMT In article <3aqvp1$4ad@agate.berkeley.edu>, Michael Constant wrote: >Jay "Thierry" Han wrote: >> mconst@soda.CSUA.Berkeley.EDU (Michael Constant) writes: >>> James J Jesensky wrote: >>> >Here's an idea for a future hill or tournament. Run all the programs >>> >together instead of two at a time. I think in this type of run-time >>> >enviroment will require new programming strategies to be successful. >>> >>> [ mconst saying "it won't work" ] >> >>I'm not sure. A fast stone at start-up may do a lot of damage. > >A fast stone certainly would do a lot of damage... but that doesn't >mean that the stone will score well! The stone will quickly be killed >by something, since it has no defenses at all and it is being attacked >by 19 other programs. The poor stone will have sacrificed itself for >the greater good, but that's not the point of corewar ;-) > >I hold by my original statment that the best-scoring programs (by far) >will be paper and imps. To do well in the crowded arena, a program >will have to survive the attacks of 19 other programs... quick offensive >programs just won't work, since they'll have to kill 19 programs before >getting hit by the crossfire. The top programs would be very fast >papers, which could survive several hits of just about anything before >dying. > >However, I'm not averse to trying a multi-program hill/tournament. >It would certainly be a change from the regular one-on-one battles... >but I think it would quickly degenerate into rather boring programs. >-- > Michael Constant (mconst@soda.csua.berkeley.edu) I agree that under standard single warrior scoring rules, the contest would degenerate into defensive programs, but it wouldn't if you were allowed to submit multiple programs that win together: an army. The number of warriors in an army would be the same (or fewer--Rambo takes on multiple armies and comes out grinning) for all armies on a given hill. If any subset of the initial army survives, the army wins. This would allow for a wider range of strategies: since you could afford to lose a program or two, you could have offense specialists and defense specialists working together. The offense specialists might get wiped out every time, but they'd (hopefully) take out most of the resistance, and the defense specialist could then mop up. Despite this teamwork, the warriors in an army would be separate programs. They would be loaded into memory separately (although they might be passed info on where the other members of their army are) and they would not use each other's clock cycles. Of course, this is just the barest of descriptions, but as I am a corewar newbie (see my other post) I will leave it to the more experienced hands to thrash out the details. --The Twilight Hunter From: stu1136@discover.wright.edu (Eric Moyer) Subject: What do the displays mean? Message-ID: Date: Wed, 23 Nov 1994 01:45:41 GMT Could someone explain what the graphical/text mode displays of the core in pMars mean. I am trying to debug/design my first warrior, and I think that the displays would be of assistance in understanding why it always gets trounced-- if I could just understand them. Thanks, --The Twilight Hunter From: ama@athena.mit.edu (Albert Ma) Subject: Re: Let's run all the programs at once Date: 23 Nov 1994 04:08:47 GMT Message-ID: <3auf8f$i6p@senator-bedfellow.MIT.EDU> In article <3aqqik$7gk@news.asu.edu> sieben@imap1.asu.edu writes: >James J Jesensky (jesensky@mix.cse.psu.edu) wrote: >: * It should be rather simple to modify MARS code to handle >2 programs >: in the core. > >It could be little bit of work to change pMars, it wasn't considered at all >during the construction of the data structure to make this change easy. Actually, it shouldn't be that hard. We have that weird nextWarrior functionality that makes it easy to expand to many warriors. That doesn't affect speed at all. what might affect speed is if we had to dynamically allocate some data structures to accomodate any number of warriors. But we wouldn't need to do this unless we wanted to do lots of warriors. Most of our data structures are small. You guys think this is a worthwhile effort? I can devote a little bit of time on it this saturday and sunday. Albert Ma ama@mit.edu From: pk6811s@acad.drake.edu Subject: Taking Names Date: 23 Nov 94 15:44:04 CST Message-ID: <1994Nov23.154404@acad.drake.edu> Here is the source for Taking Names, using a sne/seq combination to scan core at 80% of c (4 locations in a 5-instruction loop). It drops a spl-spl-jmp bomb on anything it finds. I started out with the usual spl-jmp bomb but realized during testing that against certain opponents it gave too many ties. Like when it was dropped on someone's core-clear, the opponent may still have been able to cripple or even kill Taking Names. Making the bomb one instruction wider seemed to give more wins, particularly against Blue Funk 3, attacking the DAT -7 instruction now cripples the whole stone. Against the Silk-style replicators the wider bomb gives significantly more wins. The sne/seq combination makes for faster scanning but of course makes TN larger. It seems to balance out a little on the favorable side. I dropped the sne in one trial and lost a few points. Using the .X modifier gives up a few points - it only compares the values of the a- and b-operands, not the whole instruction, but we'll see how it works to frustrate reflections. With the majority of the b-operands referencing 'comp' it was easy to set up a pointer to comp that gives both decrement AND increment protection. If you are not familiar with decrement-protection check out the '@compptr' references and imagine what happens when those b-operands are decremented by a stone using MOV clrptr ; continuous forward clear kills imps for sure jump jmp -1 for 30 dat 0,0 rof for 12 dat #1,1 ; simple decoy mov.i #attack+1000,2667 rof end comp From: Brian@quinion.demon.co.uk (Brian Quinion) Subject: CoreWar - not everything is in the FAQ... Date: Thu, 24 Nov 1994 16:02:07 +0000 Message-ID: <785692927snz@quinion.demon.co.uk> In most of the posts I've seen to date there has been the assumption of a certain level of knowledge, which seems to include a high level of understanding of a large number of types of redcode program and they way that they are coded. Is there anywhere I can find stereo typical examples (preferably with good commenting) of the various types and the reasoning behind them? -- Brian Quinion From: mreddy@glamorgan.ac.uk (Mike Reddy) Subject: FAQ for C++ Robots? Message-ID: Date: Thu, 24 Nov 1994 18:46:03 GMT Simply put, is there a FAQ for C++ Robots? Yours Mike Reddy -- P.S. I would have had a witty signature, but the Government put VAT on it! P.P.S. I live at mreddy@uk.ac.glamorgan OR mreddy@glamorgan.ac.uk if you are unlucky enough to live outside the UK! 8-) Snail Mail: Mike Reddy, J228, Dept. of Computer Studies, University of Glamorgan, Pontypridd, Mid Glamorgan. CF37 1DL Wales, UK Tel: +44 (0)443 482 240 Fax: +44 (0)443 482 715 From: bmellows@jolt.mpx.com.au (Bruce Mellows) Subject: Re: Make corewar programs do something Date: 26 Nov 1994 04:19:43 GMT Message-ID: <3b6d0v$jhq@inferno.mpx.com.au> georgel@gas.uug.arizona.edu wrote: : When I read the original articles about corewar, it is talking : about the winner getting control over the memory and the computers : recources. Well there aren't any. How about add an instruction at random [ 8< SNIP 8< ] : Comments? : George My comment is as follows... I do enjoy reading this news group and (ocassionally) coding warriors and have shared this same thought (no final goal of the warrior) The way I see it (not IMHO :) assembley code for *ANY* computer should be capable of doing something, and redcode would be useless for anything other than warriors (its just barely adequate for that) If that all sounds like pointless complaining, Im sorry, but thats how it is. BTW. :) :) (JIC) Bruce Mellows (bmellows@mpx.com.au) From: sieben@imap1.asu.edu Subject: Re: Make corewar programs do something Date: 26 Nov 1994 20:26:24 GMT Message-ID: <3b85lg$ekp@news.asu.edu> : My comment is as follows... : I do enjoy reading this news group and (ocassionally) coding warriors : and have shared this same thought (no final goal of the warrior) : The way I see it (not IMHO :) assembley code for *ANY* computer : should be capable of doing something, and redcode would be useless : for anything other than warriors (its just barely adequate for that) : If that all sounds like pointless complaining, Im sorry, but thats : how it is. : Bruce Mellows (bmellows@mpx.com.au) The goal is to kill the opponent. Isn't it a clear goal. Redcode is capable of anything. This was proven by the prime finding round of the no eliminating tournament. Nandor. From: George Lebl Subject: Re: Make corewar programs do something Date: Sun, 27 Nov 1994 14:26:00 -0700 Message-ID: On 26 Nov 1994 sieben@imap1.asu.edu wrote: > > The goal is to kill the opponent. Isn't it a clear goal. Redcode is > capable of anything. This was proven by the prime finding round of the no > eliminating tournament. > > Nandor. > > Well what I thought, was there is no outside world for the programs, the computer isn't just the memory, If a redcode is a virtual computer, why not put all the bells and whistles, how about a video ram to use for storing programs code it could use, Saving itself on a hard drive (another 8000 instruction world, which could though be only read) these devices would be accesed though random memory locations which the program would have to find. This of coururse is just adding the capabilities to redcode as a warrior. In the first article I said the programs would have to do something, why not. Executing a WIN instruction at a memory location chosen random would give the program control of the machine, and would not need to kill the other opponent. As I said this would make the opponents to be more inteligent, instead of just blind bombing. George ------------------------------------------------------------------------------ ___ | George Lebl FRANZ / | \ | georgel@gas.uug.arizona.edu | | | /|\ | | Sex Pistols RULE! |-O-| \/_|_\/ | The force is with you | | From: natewild@mbnet.mb.ca (Nathan T. Wild) Subject: Call For Submissions Date: 28 Nov 1994 14:09:20 GMT Message-ID: <3bcoag$7rp@canopus.cc.umanitoba.ca> I need sample source code for CRobots, C++Robots and PCRobots (preferably the latter) for a WebPage I am establishing. Please send me any useful source (active 'bots or test-drones) or even useful functions/algorithms. Please email submissions to me at this address and please clearly state your name and any credits you wish to be reflected on the link. I am also setting up a CoreWar link in the same page, so if anyone can tell me of any other good W3 pages related to any of the above programs or CoreWar. RSVP... The sooner the better... -- Later: Nate... ------------------------------------------------------------------------ | Nathan T. Wild | Retail Systems | (204) 631-7378 VOX | | natewild@mbnet.mb.ca | Codville Distributors | (204) 694-2948 FAX | ------------------------------------------------------------------------ - A C++ Programmer Is Always Willing To Try New Things - Message-ID: <5aioCRj-2zB@ra15.rman2.gun.de> From: f.low@rman2.gun.de (Florian Gewecke) Subject: S: FAQ ! Date: 28 Nov 1994 14:10:00 +0200 Hi all, I'd also like to know, if there's a FAQ, and maybe a hint, where to get the program ! ThanX, Florian From: pk6811s@acad.drake.edu Subject: Re: Easy carpet bomber Date: 28 Nov 94 15:23:22 CST Message-ID: <1994Nov28.152322@acad.drake.edu> In article <3at8m3$61s@news.CCIT.Arizona.EDU>, georgel@gas.uug.arizona.edu writes: > To make a carpet bomber, all you need is an offset that will bomb > instructions, not linearly, but rather everywhere first. > > Any dwarf can do this, to find out the offset, take the usual offset > number and multiply it by a number that is not a dividend of coresize, > (n/CORESIZE)<>INT(n/CORESIZE) > > e.g. > > 4 * 11 > > every fourth location will be bombed, these are bombed at intervals of 11. > This is great! How come I never heard about this hint? One of the drawbacks of using this approach is the 'shadow' cast by your own code through core. Since the carpet has to stop before eating up your code there will be unbombed spaces every N locations where N is the interval you choose above. But it's still a neat technique. Paul Kline pk6811s@acad.drake.edu Hey Brant, good luck on that Vampire! From: e9125110@stud1.tuwien.ac.at (MARTIN MAIERHOFER) Subject: Where to find C(++) Robots ? Date: 28 Nov 1994 15:24:16 GMT Message-ID: <3bcsn0$9md@news.tuwien.ac.at> Could someone please point me to an ftp site where I can find the sources for CBots/C++ Robots (I think they can be used with Linux, can't they ?). Thanks, Martin -- Martin Maierhofer | "History will teach us nothing." e9125110@student.tuwien.ac.at | - Sting From: George Lebl Subject: Re: Easy carpet bomber Date: Mon, 28 Nov 1994 20:29:06 -0700 Message-ID: On 28 Nov 1994 pk6811s@acad.drake.edu wrote: > In article <3at8m3$61s@news.CCIT.Arizona.EDU>, georgel@gas.uug.arizona.edu writes: > > To make a carpet bomber, all you need is an offset that will bomb > > instructions, not linearly, but rather everywhere first. > > > > Any dwarf can do this, to find out the offset, take the usual offset > > number and multiply it by a number that is not a dividend of coresize, > > (n/CORESIZE)<>INT(n/CORESIZE) > > > > e.g. > > > > 4 * 11 > > > > every fourth location will be bombed, these are bombed at intervals of 11. > > > > This is great! How come I never heard about this hint? > > One of the drawbacks of using this approach is the 'shadow' cast by your > own code through core. Since the carpet has to stop before eating up your > code there will be unbombed spaces every N locations where N is the interval > you choose above. Actually the code is not eaten up since the interval is not 11, but 11 * 4, that is 44, this way it will bomb every 4th location, just as a regular dwarf, but starting from everywhere. > > But it's still a neat technique. > Too bad I didn't think of it first! > Paul Kline > pk6811s@acad.drake.edu > George ------------------------------------------------------------------------------ ___ | George Lebl FRANZ / | \ | georgel@gas.uug.arizona.edu | | | /|\ | | Sex Pistols RULE! |-O-| \/_|_\/ | The force is with you | | From: George Lebl Subject: Re: Easy carpet bomber Date: Mon, 28 Nov 1994 21:22:07 -0700 Message-ID: There is a calculator of the optima numbers in the mars88.zip archive, named optima.exe. George ------------------------------------------------------------------------------ ___ | George Lebl FRANZ / | \ | georgel@gas.uug.arizona.edu | | | /|\ | | Sex Pistols RULE! |-O-| \/_|_\/ | The force is with you | | From: rrognlie@netcom.com (Richard Rognlie) Subject: Re: Where to find C(++) Robots ? Message-ID: Date: Tue, 29 Nov 1994 02:41:44 GMT MARTIN MAIERHOFER (e9125110@stud1.tuwien.ac.at) wrote: : Could someone please point me to an ftp site where I can find the : sources for CBots/C++ Robots (I think they can be used with Linux, : can't they ?). I can't vouch for Cbots, but C++Robots is only available for Sun SPARC right now. At some point in the future, the simulator *may* be portable to other platforms, but right now there are too many byte ordering, word size dependencies. Also, the simulator uses SUN SPARC .o files (generated by GNU C++) as input. If you have a cross compiler version of GNU C++ on your linux box, you could generate SPARC .o from your PC and then use that as input to the simulator. But until I finish polishing the simulator I'm afraid you're stuck. Sorry, Richard -- /\/\/\ | Richard Rognlie / Sr. Computer Analyst / PRC Inc. / McLean, VA / \ \ \ | E-Mail: rrognlie@netcom.com *or* rognlie_richard@prc.com \ / / / | Phone: (Home) (703) 361-4764 (Office) (703) 556-2458 \/\/\/ | (Fax) (703) 556-1174 From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) Subject: Re: Make corewar programs do something Date: 29 Nov 1994 20:21:48 GMT Message-ID: <3bg2gs$bl2@agate.berkeley.edu> George Lebl wrote: >On 26 Nov 1994 sieben@imap1.asu.edu wrote: >> The goal is to kill the opponent. Isn't it a clear goal. Redcode is >> capable of anything. This was proven by the prime finding round of the no >> eliminating tournament. > >Well what I thought, was there is no outside world for the programs, the >computer isn't just the memory, If a redcode is a virtual computer, why >not put all the bells and whistles, how about a video ram to use for >storing programs code it could use, Saving itself on a hard drive >(another 8000 instruction world, which could though be only read) these >devices would be accesed though random memory locations which the program >would have to find. I don't think this would work very well. What would be the point of using external storage? Corewar programs don't need it. The only time a program could ever make use of extra storage would be in a calculating competition, such as the prime number round of my mini-tournament. >This of coururse is just adding the capabilities to redcode as a warrior. >In the first article I said the programs would have to do something, why >not. Executing a WIN instruction at a memory location chosen random would >give the program control of the machine, and would not need to kill the >other opponent. As I said this would make the opponents to be more >inteligent, instead of just blind bombing. On the contrary, it would make competitors stupider and add more chance to the battle. Scanning for a single instruction out of 8000 is not feasible; therefore, a program's only hope would be to execute lots of random instructions. This is a pretty easy program to write (a paper that spends a lot of time jumping to random locations). Besides, modern corewar programs tend to be pretty intelligent. There is a lot of science to be found in warfare ;-) -- Michael Constant (mconst@soda.csua.berkeley.edu) From: unbelver@bashful.cc.utexas.edu (Carlos Y. Villalpando) Subject: 1995 UT IEEE CS National Programming Contest Date: 29 Nov 1994 23:18:19 -0600 Message-ID: <3bh1ur$rns@bashful.cc.utexas.edu> NPC update! Because of construction plans in our bilding, we were down for a couple of weeks. We are now up at a new IP address. Your namserver should already have it. If not, we are now at 128.83.198.136. We now have prize updates!!! Thanks to Micron Technologies and Quarterdeck for their donations of 3 486 Multimedia Computers and Desqview X developer's kits! Send in your apps NOW!!! :-----------------------------------------------------------------------------: ANNOUNCING THE 1995 IEEE-CS NATIONAL PROGRAMMING CONTEST :-----------------------------------------------------------------------------: EVENT: The 1995 IEEE Computer Society (inter)National Programming Contest WHERE: University of Texas at Austin, USA DATE: March 25, 26 1995 :-----------------------------------------------------------------------------: FREQUENTLY ASKED QUESTIONS ABOUT THE NATIONAL PROGRAMMING CONTEST Q: What is the IEEE CS National Programming Contest (NPC)? A: The NPC is an invitational computer programming contest which challenges 16 of the finest undergraduate student programing teams in the world to compete against each other in a new and exciting contest format. Each school sends a team of three students. These three students are given just one day to write a 'player', a program which will compete against other players in a game created for the contest by the NPC organizers. The nature of the game will not be revealed until the contest day. Last year, contestants wrote players that flew space ships around an arena which tried to bump or shoot each other out of the arena. Sources written by last years teams and binaries are available by anonymous ftp from npc.ece.utexas.edu in /pub/Space_Brawl_NPC94/. Q: What is the format of the National Programming Contest? A: On Friday night, the contestants will meet at the hotel for an introductory assembly and registration. Although the contest doesn't begin until Saturday morning, we ask the teams to arrive Friday evening, as this information session is very important. Team packets containing information about the game will be distributed at this time. On Saturday, the first contest day, the contestants will be transported to IBM for the day of programming. Approximately 18 hours over Saturday and Sunday will be allowed for programming. On Sunday, the second day of the contest, after a couple of hours of final work, the contestants' programs fight each other for first place. The contest will conclude with an awards ceremony and prize distribution. The 1995 NPC will be held at IBM's Austin facility. The programming and gameplay will take place on 50 IBM RS/6000 UNIX workstations linked through a token-ring network. The contestants will use C++ to write their programs. We ask that at least one member of the team be experienced with C++ programming in a UNIX environment. It is usually best if all three teammates know C++ programming. Q: Who may compete in the National Programming Contest? A: Although the NPC was originally intended to be only a national event, we are getting interest from international schools. We encourage these schools to submit applications if they are interested in sending a team. Teams will no longer be invited automatically, as we only have room for 16 teams. All teams interested in competing are encouraged to apply. All competitors must be undergraduate students (or equivalent) in their major on the day of the contest. If this requirement is not clear or your country uses a different system, please mail us for clarification, as this rule will be strictly enforced. All teams must consist of exactly three competitors. You DO NOT have to be a member of IEEE or IEEE-CS to compete. Q: Are there any contest fees for NPC? A: The NPC is free to the competitors. The sponsors of NPC will pay for all food during the contest days and all transportation between the hotel and contest site. To arrange for more than one hotel room or for rental cars, please phone ahead. The NPC will not cover the cost of transportation to and from Austin. However, you will be notified in time to arrange for reduced-rate advance air fares. Q: How old is the NPC? This is the fourth incarnation of the NPC. The first contest was held at the University of Texas on November 21, 1991 and last year's contest was held March 26th and 27th at IBM in Austin, Texas. IBM has graciously agreed to host our contest again this year. The winner of last year's contest was the team from Stanford University, Q: What are the prizes? A: Last year, Micron donated 3 486 computers and Watcom donated 9 of their 32-Bit Professional C compilers. This year's prizes are in the works. Stay tuned for more details. Q: What is the format of the application? A: Please submit applications via e-mail. There is no limit on size except common-sense. We will be looking over each application very carefully and may send mail back to you for clarifications. If you ABSOLUTELY don't have access to e-mail, we can be reached at: National Programming Contest University of Texas at Austin ENS 103 Austin, TX 78712 Please allow as much time as is necessary for your mail to reach us by the deadline. (This can be up to and over three weeks for international mail) And for our reply to reach you. Also remember that 'snail-mail' is not very reliable compared to e-mail, so we may not even receive your application if you send it in this manner. In the past, we've had trouble with several teams from a school having members with similar qualifications. The selection committee can use every bit of relevant information in making their decision (i.e. Computer-related experience, activities, honors & awards) Previous programming-contest experience is a plus, and could be used as a tie-breaker in making the selections. We must remind you that only one team will be selected per school, and each team must have three members. Please include the following information in your application: 1) Names of the three team members 2) E-mail address of a sponsor or contact (may be a member of the team) 3) School 4) Major of each member 5) Programming experience, honors, awards, activities & clubs (computer-related), and any other relevant info. If you have experience with programming AI, then include that. If you know some obscure language, then let us know. If you don't receive acknowledgement of your application withing one week, please resubmit it. Though you should receive an immediate reply, sometimes things can be lost in the shuffle. The application deadline is midnight, December 31, 1994. All applicants will be notified of their status by January 15th, 1995 at the latest. Q: Who is organizing this event? A: This event is organized by the students of the IEEE-CS Student Branch Chapter at the University of Texas at Austin, USA. With the help of some (in)voluntary recruits. Q: WHY do you do this? A: That's a hard one. Believe it or not, we have a lot of fun writing the game. (Which is half the work) Meetings are held weekly, with various tasks assigned to different people. These include writing the server, the API, the graphics server, sound, and various other programming tasks. Most of us plan to go into computer-related fields after graduation, and this is a step in that direction. Others, while involved in other fields, just have fun working with computers as a hobby. And, if the hard work weren't fulfillment enough (it isn't) the contest itself is a very exciting event for all who participate. Q: What if we want to start a contest at our school? A: Go for it. You'll need people to help program, to raise funds, to get sponsors, and to organize. And of course, you'll need contestants. For a smaller contest, you can host one at a local level, with a small entry fee to buy pizza for a small-scale one day contest. These can be organized very quickly, with minimal overhead. The NPC, however is very large-scale, and has been in development for the last four years, always growing. Work on next year's contest will begin the day after, and possibly before this year's contest. Always remember that you can re-use code and ideas from previous contests. :-----------------------------------------------------------------------------: APPLICATION DEADLINE: January 15, 1994 SEND APPLICATIONS TO: apply@npc.ece.utexas.edu SEND QUESTIONS TO: answers@npc.ece.utexas.edu :-----------------------------------------------------------------------------: From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 30 Nov 1994 12:36:00 GMT Message-ID: Archive-name: games/corewar-faq Last-modified: 1994/11/25 Version: 2.3.1 These are the Frequently Asked Questions (and answers) from the USENET newsgroup rec.games.corewar. This FAQ list is also available by anonymous FTP from rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.Z. TABLE OF CONTENTS Line ------------------------------------------------------------------------ 1. What is Core War? 69 2. Is it Core War or Core Wars? 82 3. Where can I find more information about Core War? 90 4. Core War has changed since Dewdney's articles. Where do I get 116 a copy of the current instruction set? 5. What is ICWS'94? Which simulators support ICWS'94? 135 6. What is the ICWS? 152 7. What is TCWN? 162 8. How do I join? 170 9. Are back issues of TCWNs available? 187 10. What is the EBS? 194 11. Where are the Core War archives? 208 12. Where can I find a Core War system for . . . ? 226 13. I do not have ftp. How do I get all of this great stuff? 275 14. I do not have access to Usenet. How do I post and receive news? 285 15. When is the next tournament? 303 16. What is KotH? How do I enter? 314 17. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 483 18. How does SLT (Skip if Less Than) work? 495 19. What does (expression or term of your choice) mean? 507 20. Other questions? 650 --------------------------------------------------------------------- Q 1: What is Core War? A 1: 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 posession 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. ---------------------------------------------------------------------- Q 2: Is it "Core War" or "Core Wars"? A 2: 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. ---------------------------------------------------------------------- Q 3: Where can I find more information about Core War? A 3: 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 two anthologies: Author: Dewdney, A. K. Title: The Armchair Universe: An Exploration of Computer Worlds Published: New York: W. H. Freeman (c) 1988 ISBN: 0-7167-1939-8 Library of Congress Call Number: QA76.6 .D517 1988 Author: Dewdney, A. K. Title: The Magic Machine: A Handbook of Computer Sorcery Published: New York: W. H. Freeman (c) 1990 ISBN: 0-7167-2125-2 (Hardcover), 0-7167-2144-9 (Paperback) Library of Congress Call Number: QA76.6 .D5173 1990 A.K. Dewdney's articles are still the most readable introduction to Core War, even though the Redcode dialect described in there is no longer current (see Q 4). --------------------------------------------------------------------- Q 4: Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? A 4: A draft of the official standard (ICWS'88) is available by anonymous FTP from the Core War archives (ftp.csua.berkeley.edu) as pub/corewar/documents/standards/redcode-icws-88.Z This document is formatted awkwardly and contains ambiguous statements. For a more approachable intro to Redcode, take a look at pub/corewar/documents/tutorial.1.Z tutorial.2.Z (See also Q11) Steven Morrell (morrell@math.utah.edu) is preparing a more practically oriented Redcode tutorial that discusses different warrior classes with lots of example code. Mail him for a preliminary version. Michael Constant (mconst@ ftp.csua.berkeley.edu) is reportedly working on a beginner's introduction. --------------------------------------------------------------------- Q 5: What is ICWS'94? Which simulators support ICWS'94? A 5: There is an ongoing discussion about future enhancements to the Redcode language. A proposed new standard, dubbed ICWS'94, is currently being evaluated. A major change is the addition of "instruction modifiers" that allow instructions to modify A-field, B-field or both. Also new is a post-increment indirect addressing mode and unrestricted opcode and addressing mode combination ("no illegal instructions"). ICWS'94 is backwards compatible; i.e. ICWS'88 warriors will run correctly on an ICWS'94 system. Take a look at the ICWS'94 draft for more information (ftp.csua.berkeley.edu pub/corewar/documents/icws94.0202.Z). You can try out the new standard by submitting warriors to the '94 hills of the KotH servers (see Q16). Two corewar systems currently support ICWS'94, pMARS (various platforms) and Redcoder (Mac), both available at soda (see Q12). --------------------------------------------------------------------- Q 6: What is the ICWS? A 6: 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). --------------------------------------------------------------------- Q 7: What is TCWN? A 7: Since March of 1987, "The Core War Newsletter" (TCWN) has been the official newsletter of the ICWS. It is published quarterly and recent issues are also available as Encapsulated PostScript on ftp.csua.berkeley.edu (see Q9). --------------------------------------------------------------------- Q 8: How do I join? A 8: For more information about joining the ICWS (which includes a subscription to TCWN), or to contribute an article, review, cartoon, letter, joke, rumor, etc. to TCWN, please contact: Jon Newman 13824 NE 87th Street Redmond, WA 98052-1959 email: jonn@microsoft.com (Note: Microsoft has NO affiliation with Core War. Jon Newman just happens to work there, and we want to keep it that way!) Current annual dues are $15.00 in US currency. ---------------------------------------------------------------------- Q 9: Are back issues of TCWN available? A 9: Recent issues can be found on ftp.csua.berkeley.edu (see Q11). Older issues (up to Winter 1991) are also available (see the next TCWN for details). --------------------------------------------------------------------- Q10: What is the EBS? A10: 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 are entered into the annual ICWS tournament. All EBS business is conducted in the rec.games.corewar 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 (see Q 5). ---------------------------------------------------------------------- Q11: Where is the Core War archive? A11: 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 ftp.csua.berkeley.edu (128.32.43.51) in the /pub/corewar directories. Also, most of past rec.games.corewar postings (including Redcode source listings) are archived there. Jon Blow (blojo@ftp.csua.berkeley.edu) is the archive administrator. When uploading to /pub/corewar/incoming, ask Jon to move your upload to the appropriate directory and announce it on the net. Much of what is available on soda is also available on the German archive at iraun1.ira.uka.de (129.13.10.90) in the /pub/X11/corewars directory. This FAQ is automatically archived by news.answers. See the header for the current archive name and news.answers for how to get it. ---------------------------------------------------------------------- Q12: Where can I find a Core War system for . . . ? A12: Core War systems are available via anonymous ftp from ftp.csua.berkeley.edu in the pub/corewar/systems directory. Currently, there are UNIX, IBM PC-compatible, Macintosh, and Amiga Core War systems available there. It is a good idea to check pub/corewar/incoming for program updates first. CAUTION! There are many, many Core War systems available which are NOT ICWS'88 (or even ICWS'86) compatible available at various archive sites other than ftp.csua.berkeley.edu. Generally, the older the program - the less likely it will be ICWS compatible. Reviews of Core War systems would be greatly appreciated in the newsgroup and in the newsletter. Below is a not necessarily complete or up-to-date list of what's available at soda: MADgic41.lzh - corewar for the Amiga, v4.1 MAD4041.lzh - older version? MAD50B.lha - corewar for the Amiga, beta version 5.0 Redcoder-21.hqx - corewar for the Mac, supports ICWS'88 and '94 core-11.hqx - corewar for the Mac core-wars-simulator.hqx - same as core-11.hqx? corewar_unix_x11.tar.Z - corewar for UNIX/X-windows, ICWS'86 but not ICWS'88 compatible koth31.tar.Z - corewar for UNIX/X-windows. This program ran the former KotH server at intel.com koth.shar.Z - older version kothpc.zip - port of older version of KotH to the PC deluxe20c.tar.Z - corewar for UNIX (broken X-windows or curses) and PC mars.tar.Z - corewar for UNIX, likely not ICWS'88 compatible icons.zip - corewar icons for MS-Windows macrored.zip - a redcode macro-preprocessor (PC) c88v49.zip - PC corewar, textmode display mars88.zip - PC corewar, graphics mode display corwp302.zip - PC corewar, textmode display, slowish mercury2.zip - PC corewar written in assembly, fast! mtourn11.zip - tournament scheduler for mercury (req. 4DOS) pmars06s.zip - portable system, ICWS'88 and '94, runs on UNIX, PC, Mac, Amiga. C source archive pmars06s.tar.Z - same as above pmars062.zip - PC executables with graphics display, req 386+ macpmars02.sit.hqx - pMARS executable for Mac (port of version 0.2) buggy, no display MacpMARS.10.cpt.hqx - port of v0.6 for the Mac, with display and debugger MacpMARS.10s.cpt.hqx - C source (MPW, ThinkC) for Mac frontend ApMARS03.lha - pMARS executable for Amiga (port of version 0.3.1) wincor11.zip - MS-Windows system, shareware ($15) ---------------------------------------------------------------------- Q13: I do not have ftp. How do I get all of this great stuff? A13: There is an ftp email server at ftpmail@decwrl.dec.com. Send email with a subject and body text of "help" (without the quotes) for more information on its usage. If you don't have access to the net at all, send me a 3.5 '' diskette in a self-addressed disk mailer with postage and I will mail it back with an image of the Core War archives in PC format. My address is at the end of this post. ---------------------------------------------------------------------- Q14: I do not have access to Usenet. How do I post and receive news? A14: To receive rec.games.corewar articles by email, join the COREWAR-L list run on the Stormking.Com ListProcessor. To join, send: SUB COREWAR-L FirstName LastName to: LISTPROC@STORMKING.COM You can send mail to corewar-l@stormking.com to post even if you are not a member of the list. Responsible for the listserver is Scott J. Ellentuch (tuc@stormking.com). Another server that allows you to post (but not receive) articles is available. Email your post to rec-games-corewar@cs.utexas.edu and it will be automatically posted for you. ---------------------------------------------------------------------- Q15: When is the next tournament? A15: The ICWS holds an annual tournament. Traditionally, the deadline for entering is the 15th of December. The EBS usually holds a preliminary tournament around the 15th of November and sends the top finishers on to the ICWS tournament. Informal double-elimination tournaments are held frequently among readers of the newsgroup; watch there for announcements or contact me. ---------------------------------------------------------------------- Q16: What is KotH? How do I enter? A16: King Of The Hill (KotH) is an ongoing Core War tournament available to anyone with email. You enter by submitting via email a Redcode program with special comment lines. You will receive a reply indicating how well your program did against the current top twenty programs "on the hill". Your program will play 100 battles against each of the 20 other programs currently on the Hill. You receive 3 points for each win and 1 point for each tie. (The existing programs do not replay each other, but their previous battles are recalled.) All scores are updated to reflect your battles and all 21 programs are ranked from high to low. If you are number 21 you are pushed off the Hill, if you are higher than 21 someone else is pushed off. The original KotH was developed and run by William Shubert at Intel, and discontinued after almost three years of service. Currently, KotHs based on Bill's UNIX scripts but offering a wider variety of hills are are running at two sites: "koth@stormking.com" is maintained by Scott J. Ellentuch (tuc@stormking.com) and "pizza@ecst.csuchico.edu" by Thomas H. Davies (sd@ecst.csuchico.edu). Both KotHs provide very similar services and are therefore covered together. The principal difference is that "pizza" has a much faster internet connection than "stormking". 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 a line starting with ";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. (Also, see 5 below). 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 daemon 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. There are currently six separate hills you can select by starting your program with ;redcode, ;redcode-x, ;redcode-icws, ;redcode-b, ;redcode-94, or ;redcode-94x. More information on these hills is listed below. 3) Mail this file to "koth@stormking.com" or "pizza@ecst.csuchico.edu". "Pizza" requires a subject of "koth" (use the -s flag on most mailers). 4) Within a few minutes (or the next day for "stormking") you should get mail back telling you whether your program assembled correctly or not. If it did assemble correctly, sit back and wait; if not, make the change required and re-submit. 5) In an hour or so (or the next day for "stormking") you should get more mail telling you how your program performed against the current top 20 programs. If no news arrives during that time, don't worry; entries are put in a queue and run through the tournament one at a time. A backlog may develop. Be patient. If your program makes it onto the hill, you will get mail every time a new program makes it onto the hill. If this is too much mail, you can use ";redcode quiet" when you first mail in your program; then you will only get mail when you make it on the top 20 list or when you are knocked off. Using ";redcode verbose" will give you even more mail; here you get mail every time a new challenger arrives, even if they don't make it onto the top 20 list. Often programmers want to try out slight variations in their programs. If you already have a program named "foo V1.0" on the hill, adding the line ";kill foo" to a new program will automatically bump foo 1.0 off the hill. Just ";kill" will remove all of your programs when you submit the new one. The server kills programs by assigning an impossibly low score; it may therefore take another successful challenge before a killed program is actually removed from the hill. SAMPLE ENTRY: ;redcode ;name Dwarf ;author A. K. Dewdney ;strategy Throw DAT bombs around memory, hitting every 4th memory cell. ;strategy This program was presented in the first Corewar article. bomb DAT #0 dwarf ADD #4, bomb MOV bomb, @bomb JMP dwarf END dwarf ; Programs start at the first line unless ; an "END start" pseudo-op appears to indicate ; the first logical instruction. Also, nothing ; after the END instruction will be assembled. Here are the Specs for the various hills: ICWS'88 Standard Hill Specs: (Accessed with ";redcode", available at "stormking" and "pizza") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '88 ICWS Annual Tournament Hill Specs: (Accessed with ";redcode-icws", available at "stormking" only) coresize: 8192 instructions max. processes: 8000 per program duration: After 100,000 cycles, a tie is declared. max. entry length: 300 minimum distance: 300 instruction set: ICWS '88 ICWS'88 Experimental (Small) Hill Specs: (Accessed with ";redcode-x", available at "pizza" only) coresize: 4096 max. processes: 32 duration: after 65,536 cycles, a tie is declared. max. entry length: 64 minimum distance: 64 instruction set: ICWS '88 ICWS'94 Draft Hill Specs: (Accessed with ";redcode-94", available at "stormking" and "pizza") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '94 Draft ICWS'94 Beginner's Hill Specs: (Accessed with ";redcode-b", available at "pizza" only) coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '94 Draft ICWS'94 Experimental (Big) Hill Specs: (Accessed with ";redcode-94x", available at "stormking" and "pizza") coresize: 55440 max. processes: 10000 duration: after 500,000 cycles, a tie is declared. max. entry length: 200 minimum distance: 200 instruction set: ICWS '94 Draft If you just want to get a status report without actually challenging the hills, send email with ";status" as the message body (and don't forget "Subject: koth" for "pizza"). If you send mail to "pizza" with "Subject: koth help" you will receive instructions that may be more up to date than those contained in this document. All hills run portable MARS (pMARS) version 0.6, a platform-independent corewar system available at soda (see Q12). The '94 and '94x hills allow three experimental opcodes and addressing modes currently not covered in the ICWS'94 draft document: SEQ - Skip if EQual (synonym for CMP) SNE - Skip if Not Equal NOP - (No OPeration) * - indirect using A-field as pointer { - predecrement indirect using A-field } - postincrement indirect using A-field ---------------------------------------------------------------------- Q17: Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? A17: Core is initialized to DAT 0, 0. This is an "illegal" instruction under ICWS'88 rules and strictly compliant assemblers (such as KotH or pmars -8) will not let you write a DAT 0, 0 instruction - only DAT #0, #0. So this begs the question, how to compare something to see if it is empty core. The answer is, most likely the instruction before your first instruction and the instruction after your last instruction are both DAT 0, 0. You can use them, or any other likely unmodified instructions, for comparison. Note that under ICWS'94, DAT 0, 0 is a legal instruction. ---------------------------------------------------------------------- Q18: How does SLT (Skip if Less Than) work? A18: SLT gives some people trouble because of the way modular arithmetic works. It is important to note that all negative numbers are converted to positive numbers before a battles begins. Example: (-1) becomes (M - 1) where M is the memory size. Once you realize that all numbers are treated as positive, it is clear what is meant by "less than". It should also be clear that no number is less than zero. ---------------------------------------------------------------------- Q19: What does (expression or term of your choice) mean? A19: Here is a selected glossary of terms. If you have a definition and/or term you wish to see here, please send it to me. (References to an X-like program mean that the term X is derived from the specific program X and has become a generic term). Bootstrapping - Strategy of copying the active portion of the program away from the initial location, leaving a decoy behind and making the relocated program as small as possible. B-Scanners - Scanners which only recognize non-zero B-fields. example add #10,scan scan jmz example,10 C - Measure of speed, equal to one location per cycle. Speed of light. CMP-Scanner - A Scanner which uses a CMP instruction to look for opponents. example add step,scan scan cmp 10,30 jmp attack jmp example step dat #20,#20 Color - Property of bombs making them visible to scanners, causing them to attack useless locations, thus slowing them down. example dat #100 Core-Clear - code that sequentially overwrites core with DAT instructions; usually the last part of a program. Decoys - Bogus or unused instructions meant to slow down Scanners. Typically, DATs with non-zero B-fields. DJN-Stream (also DJN-Train) - Using a DJN command to rapidly decrement core locations. example . . . . . . djn example,<4000 Dwarf - the prototypical small bomber. Gate-busting - (also gate-crashing) technique to "interweave" a decrement-resistant imp-spiral (e.g. MOV 0, 2668) with a standard one to overrun imp-gates. Hybrids - warriors that combine two or more of the basic strategies, either in sequence (e.g. stone->paper) or in parallel (e.g. imp/stone). Imp - Program which only uses the MOV instruction. example MOV 0, 1 or example MOV 0, 2 MOV 0, 2 Imp-Gate - A location in core which is bombed or decremented continuously so that an Imp can not pass. Also used to describe the program-code which maintains the gate. example ... ... SPL 0, Subject: Re: Make corewar programs do something Date: Wed, 30 Nov 1994 13:28:11 -0700 Message-ID: Hey, It was just an idea! George ------------------------------------------------------------------------------ ___ | George Lebl FRANZ / | \ | georgel@gas.uug.arizona.edu | | | /|\ | | Sex Pistols RULE! |-O-| \/_|_\/ | The force is with you | | From: pk6811s@acad.drake.edu Subject: Re: Make corewar programs do something Date: 30 Nov 94 13:54:13 CST Message-ID: <1994Nov30.135413@acad.drake.edu> In article <3bg2gs$bl2@agate.berkeley.edu>, mconst@soda.CSUA.Berkeley.EDU (Michael Constant) writes: >... > > Besides, modern corewar programs tend to be pretty intelligent. There > is a lot of science to be found in warfare ;-) I agree, however the intelligence is built-in, and not necessarily apparent to the reader. Such as using predecrementing dat for an imp-gate, booting, choice of step-size, stepping backward or forward, positioning dat's far from executable code, etc... These are all intelligent things to do which have benefits against certain opponents and overall give increased success. Corewars is not intended to be a super-computer. It's partly an experiment in minimalist programming, partly an exploration of numbers, partly a highly competitive game. And a chance to interact with some pretty smart people. ... Set up a multi-warrior hill and I'll be there. Sounds like fun. Paul Kline pk6811s@acad.drake.edu From: srs@shore.net (SCOTT) Subject: Final Frontier Date: 30 Nov 1994 23:43:24 GMT Message-ID: Help I don't know if it's my computer, the game or what ? This looks like a really cool game? If anyone is familiar w/ it please help me out... Thanks From: sieben@imap1.asu.edu Subject: Re: Make corewar programs do something Date: 30 Nov 1994 23:45:36 GMT Message-ID: <3bj2r0$535@news.asu.edu> pk6811s@acad.drake.edu wrote: : Set up a multi-warrior hill and I'll be there. Sounds like fun. We are working on it. Nandor.