From: rognlie@lute.gcr.com (Richard W. Rognlie) Subject: Richard's Play-By-eMail (PBeM) Server Monthly Posting Date: 1995/06/01 Message-ID: <3qjcsf$n3u@ukelele.qnet.com> newsgroups: rec.games.corewar Richard's Play-By-eMail (PBeM) Server Monthly Posting A generic Play-By-eMail Server has been set up at pbmserv@vtsu.prc.com. It currently supports a variety of games. New games for this month are: Neutron, StdTrax, Othello and Ataxx. To get more information send mail to pbmserv@vtsu.prc.com with 'help' as the subject line. Games Currently Supported 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. Ataxx On a 7x7 board, the two players of ataxx fight to controll a majority of the board via growth and jumps that flip opponents pieces to their color. 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. Neutron ((c) 1978 Charles Wetherell) On a 5x5 board, the two players of neutron fight to either move the neutron to their back row or trap it so the opponent cannot move it. The winner is the player who is able to trap the neutron or gets the neutron to his or her own back row. It does not matter if it is your opponent who moves the neutron to your back row -- you still win. Othello (Copyright (c) 1973,1990 Pressman Toy Co.) On a 8x8 board, the two players of othello fight to control the majority of the board by outflanking and flipping their opponents pieces. Tanbo & Tanbo3d (Copyright (c) 1995 Mark Steere) Played on a Go board, Tanbo crudely models a system of plant roots. Roots which are growing, competing for space, and dying. In beginner play, the roots grow much as the roots in a garden. Over time, the roots become shrewd and calculating. To win, a player must eliminate all eight of his opponent's roots. One player will always win. It's impossible to repeat a board configuration in Tanbo. Therefore a game cannot result in a draw. Tanbo3d extends the game of Tanbo into three dimensions. Terrace (Copyright (c) 1995 by Siler/Siler Ventures. All Rights Reserved) Terrace is played on an 8x8 board consisting of 16 'L' shaped terraces. Two corners of the board are "High" and the other corners are "Low". Each player has pieces of 4 sizes ('A', 'B', 'C' and 'D'). 'A' pieces are the smallest, 'D' pieces are the largest. 'T' pieces are the same size as 'A' pieces and are each player's "key" piece. The object of the game is to capture your opponent's "T" or move your "T" to the lowest square on your opponent's side of the board. Trax & StdTrax (Copyright (c) 1983 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). StdTrax limits the board to an 8x8 area. Normal Trax allows to board to grow to whatever size is necessary. Normal Trax is also known as SuperTrax. TwixT (Copyright (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. C++Robots (Copyright (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. -- /\/\/\ | Richard Rognlie / Sr. Computer Analyst / PRC Inc. / McLean, VA / \ \ \ | E-Mail: rognlie@gcr.com rrognlie@vtsu.prc.com \ / / / | Phone: (Home) (703) 361-4764 (Office) (703) 556-2458 \/\/\/ | (Fax) (703) 556-1174 From: 00ncsummers@bsuvc.bsu.edu (EL SUEN~O DE RAZON PRODUCE MONSTROS) Subject: Re: PMARS VMS port Date: 1995/06/01 Message-ID: <1995Jun1.231704.48769@bsuvc.bsu.edu>#1/1 references: <1995May31.135752.48702@orion.bsuvc.bsu.edu> newsgroups: rec.games.corewar Isn't it wierd how something you thought was written so clearly is really very poorly done? In article <1995May31.135752.48702@orion.bsuvc.bsu.edu>, I said: > I will upload a compiled and a source version (some changes were > necissary, some were cosmetic) to ftp.csua.berkeley.edu. Is there anything > else that I should do? What I meant was: I will send a copy of the port to the authors (some changes were needed, some were cosmetic) and if they give permission, I will upload a compiled and a source version to ftp.csua.berkeley.edu. Is there anything else that I should do? I certainly never meant to violate the provisions set forth in the file README. in the file pmars07s.zip. -- "If you stick your elbow out too far, Nathan Summers :) It will go home in another car." Undergraduate Student :) - a movie a friend saw in health Ball State University :) 00NCSUMMERS@BSUVC.BSU.EDU I'm not one for conspiricies, but :) nate@bsu-cs.bsu.edu here goes. I am convinced that MS:) Bob is an attempt to make Windoze :) 'Net censorship is unenforcable! look decent by comparison. :) From: pk6811s@acad.drake.edu Subject: switch code Date: 1995/06/01 Message-ID: <1995Jun1.110109@acad.drake.edu>#1/1 newsgroups: rec.games.corewar Going back to the "switch" idea I had using MUL and building on Stefan's better use of MOV.X: mov.x #-1,#1 ; <- switches 1 and -1 Using zero and non-zero would allow simpler testing: switch mov.x #0,#1 jmz.b somewhere,switch Or how about procedure-name switching: switch mov.x #proc1,#proc2 jmp.b @switch Paul Kline pk6811s@acad.drake.edu From: jkauppin@muikku.jmp.fi (Jukka Kauppinen) Subject: Info about NET-games? Date: 1995/06/05 Message-ID: <3qvmqo$m1f@muikku.jmp.fi>#1/1 newsgroups: comp.os.os2.games,comp.sys.acorn.games,comp.sys.amiga.games,comp.sys.ibm.pc.games.misc,comp.sys.mac.games,rec.games,rec.games.bolo,rec.games.corewar,rec.games.netrek,rec.games.pbm [ Article crossposted from comp.sys.amiga.games ] [ Author was Jukka Kauppinen ] [ Posted on 5 Jun 1995 22:40:28 +0300 ] Hello people. I'm looking for different ways, how a computer gamer can use Internet. There are these normal things, FTP, some special newsgroups, couple games that are located somewhere on net (like chess and backgammon) that can be played against other people. And of course, MUDs. What else? I want to know about the dizzy, special, fancy things. Are there some very special games, just made for net? Like Bolo, I've heard about it, but... Are there gaming channels on IRC? Are there some very special gaming sites, WWW/Lynx/Telnet/whatever? Is there some software, that is very handy for netgaming? What commercial games can be played using "Play By E-Mail", is that popular somewhere in the world? Simply: I am interested in everything that is connected to GAMES and INTERNET. Please E-MAIL me with everything you'd like to share with me, to "jkauppin@muikku.jmp.fi". I won't see your public postings. Thanks in forward! J#K -- Jukka O. Kauppinen Mail: Sankarinkatu 9A3,74100 IISALMI,FINLAND Journalist E-Mail: Grendel@Freenet.hut.fi Tel/fax +358-77-24225 Byterapers Inc. Amiga 500/1200(030),PC486,CD32,C64,Spectrum -- Jukka O. Kauppinen Mail: Sankarinkatu 9A3,74100 IISALMI,FINLAND Journalist E-Mail: Grendel@Freenet.hut.fi Tel/fax +358-77-24225 Byterapers Inc. Amiga 500/1200(030),PC486,CD32,C64,Spectrum From: KOTH Tourney Server Subject: SKI-ICWS: Status - Multiwarrior Experimental 94 Date: 1995/06/06 Message-ID: <199506070309.XAA29977@valhalla.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status See up to the seconds scores at http://www.stormking.com/~koth Current Status of the StormKing Industries MultiWarrior Experimental 94 CoreWar Hill: # Name Author Score Age 1 TimeScapeX (0.1) J. Pohjalainen 9120 8 2 life Nandor Sieben 7563 9 3 Ochre Jelly v1.1 Brian Zellner 7108 2 4 Shwing! T. H. Davies 6240 4 5 Lucky 13 Stefan Strack 6218 10 6 AB Scanner 2.8.1 Chris Hodson 4811 6 7 Bloody! G. Eadon 1789 1 8 Veeble Jr. T. H. Davies 973 5 9 Ochre Jelly v1.0 Brian Zellner 0 3 10 AB Scanner 2.8 Chris Hodson 0 7 11 None Nobody 0 11 12 None Nobody 0 11 13 None Nobody 0 11 14 None Nobody 0 11 15 None Nobody 0 11 16 None Nobody 0 11 17 None Nobody 0 11 18 None Nobody 0 11 19 None Nobody 0 11 20 None Nobody 0 11 21 None Nobody 0 11 From: KOTH Tourney Server Subject: SKI-ICWS: Status - MultiWarrior 94 Date: 1995/06/06 Message-ID: <199506070308.XAA28950@valhalla.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status See up to the seconds scores at http://www.stormking.com/~koth Current Status of the StormKing Industries Multiwarrior 94 CoreWar Hill: # Name Author Score Age 1 nobody special Mike Nonemacher 3019 35 2 Christmas Tie P.Kline 2854 28 3 TimeScape (1.1) J. Pohjalainen 2785 18 4 B-Panama X Steven Morrell 2726 2 5 Paper Dreaming P.Kline 2529 36 6 Ochre Jelly v1.1 Brian Zellner 2525 1 7 life Nandor Sieben 2076 37 8 Vanilla 1.3 Robert Macrae 1912 40 9 Shwing! T. H. Davies 1849 12 10 Keystone P.Kline 1268 39 11 Titan John Lewis 249 0 From: KOTH Tourney Server Subject: SKI-ICWS: Status - Standard Date: 1995/06/06 Message-ID: <199506070308.XAA34576@valhalla.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status See up to the seconds scores at http://www.stormking.com/~koth Current Status of the StormKing Industries Standard KotH CoreWar Hill : # %W/ %L/ %T Name Author Score Age 1 31/ 16/ 53 Cannonade P.Kline 146 51 2 44/ 45/ 12 bigproba nandor sieben 143 39 3 30/ 17/ 53 ttti nandor sieben 143 1 4 31/ 21/ 48 Blue Funk 88 Steven Morrell 142 15 5 47/ 53/ 0 Unknown Wolfgang Weisser 141 12 6 32/ 24/ 44 Test Wayne Sheppard 141 40 7 39/ 38/ 23 Christopher Steven Morrell 140 16 8 30/ 19/ 51 Peace Mr. Jones 140 25 9 39/ 40/ 21 Beholder's Eye V1.7 W. Mintardjo 139 95 10 42/ 44/ 14 Iron Gate Wayne Sheppard 139 145 11 41/ 45/ 13 Dagger v4.1 Michael Constant 137 60 12 32/ 27/ 41 Smoke v1.3a Brian Zellner 136 13 13 37/ 37/ 26 Keystone t21 P.Kline 136 38 14 29/ 23/ 48 CAPS KEY IS STUCK AGAIN Steven Morrell 136 17 15 36/ 38/ 25 .T.E.S.T. V0.1 P.E.M & E.C 135 48 16 23/ 14/ 63 Imps! Imps! Imps! Steven Morrell 132 62 17 29/ 27/ 44 Der Zweiter Blitzkrieg Mike Nonemacher 132 46 18 36/ 43/ 21 Titled Steven Morrell 129 14 19 27/ 27/ 46 Hydra Stephen Linhart 128 125 20 35/ 45/ 19 Summer Kitten Richard van der Brug 125 41 21 13/ 61/ 26 gen9.293 Christoph C. Birk 66 0 From: KOTH Tourney Server Subject: SKI-ICWS: Status - ICWS Tournament Date: 1995/06/06 Message-ID: <199506070308.XAA26643@valhalla.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status See up to the seconds scores at http://www.stormking.com/~koth Current Status of the StormKing Industries Annual ICWS Tournament CoreWar Hill: # %W/ %L/ %T Name Author Score Age 1 69/ 24/ 7 Agony T Stefan Strack 213 24 2 59/ 7/ 34 Cannonade Paul Kline 211 23 3 51/ 39/ 9 xtc stefan roettger 163 28 4 50/ 40/ 10 Smartbomb 4.0 Devin Kilminster 161 21 5 49/ 41/ 10 Smartbomb 4.0 Devin Kilminster 156 22 6 47/ 38/ 15 scissors matthew householder 156 38 7 48/ 41/ 11 Cat v2.0 Tim Scheer 154 20 8 44/ 40/ 16 Smart Bomb 2.2 Devin Kilminster 147 25 9 45/ 46/ 9 Irony v1.0 Brant D. Thomsen 144 27 10 42/ 41/ 17 stone matthew householder 143 35 11 30/ 33/ 36 Logan John Lewis 127 5 12 37/ 47/ 16 warrior 42 stefan roettger 127 36 13 37/ 49/ 14 doublestorm ii matthew j. chung 124 32 14 32/ 42/ 26 paper: a.k.a molerat scott nelson 122 29 15 28/ 37/ 34 Intangible Dwarf 88.3 Campbell Fraser 119 26 16 34/ 48/ 18 Trap v0.6 Wolfgang Weisser 119 2 17 27/ 37/ 36 Impetus v1.0 Michael Constant 116 18 18 32/ 50/ 18 Trap v0.6a Wolfgang Weisser 115 1 19 26/ 37/ 37 Impetus v1.0 Michael Constant 114 19 20 20/ 34/ 46 Flatline4 Thomas Nitsche 106 12 21 10/ 44/ 47 ABI '95 V1.0 Thomas Nitsche 76 0 From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 1995/06/09 Message-ID: newsgroups: rec.games.corewar,rec.answers,news.answers Archive-name: games/corewar-faq Last-Modified: 95/05/30 Version: 3.2 These are the Frequently Asked Questions (and answers) from the Usenet newsgroup rec.games.corewar. A plain text version of this document is posted every two weeks. The hypertext version is available as _________________________________________________________________ Table of Contents 1. What is Core War 2. Is it Core War or Core Wars? 3. Where can I find more information about Core War? 4. Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? 5. What is ICWS'94? Which simulators support ICWS'94? 6. What is the ICWS? 7. What is TCWN? 8. How do I join? 9. What is the EBS? 10. Where are the Core War archives? 11. Where can I find a Core War system for ...? 12. I do not have FTP. How do I get all this great stuff? 13. I do not have access to Usenet. How do I post and receive news? 14. Are there any Core War related WWW sites? 15. When is the next tournament? 16. What is KotH? How do I enter? 17. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 18. How does SLT (Skip if Less Than) work? 19. What is the difference between in-register and in-memory evaluation? 20. What does (expression or term of your choice) mean? 21. Other questions? _________________________________________________________________ What is Core War? 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 processes of the opposing program 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. [ToC] _________________________________________________________________ Is it "Core War" or "Core Wars"? 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. [ToC] _________________________________________________________________ Where can I find more information about Core War? 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. [ToC] _________________________________________________________________ Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? A draft of the official standard (ICWS'88) is available as . This document is formatted awkwardly and contains ambiguous statements. For a more approachable intro to Redcode, take a look at Mark Durham's tutorial, and . 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@csua.berkeley.edu) is reportedly working on a beginner's introduction. [ToC] _________________________________________________________________ What is ICWS'94? Which simulators support ICWS'94? 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. You can try out the new standard by submitting warriors to the '94 hills of the KotH servers. Two corewar systems currently support ICWS'94, pMARS (many platforms) and Redcoder (Mac), both available at ftp.csua.berkeley.edu. [ToC] _________________________________________________________________ What is the ICWS? 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). [ToC] _________________________________________________________________ What is TCWN? 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 files. [ToC] _________________________________________________________________ How do I join? 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. [ToC] _________________________________________________________________ What is the EBS? 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. [ToC] _________________________________________________________________ Where are the Core War archives? 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 (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@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. The plain text version of this FAQ is automatically archived by news.answers. [ToC] _________________________________________________________________ Where can I find a Core War system for . . . ? 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 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 ftp.csua.berkeley.edu: 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 (without extensions) 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) pmars07s.zip - portable system, ICWS'88 and '94, runs on UNIX, PC, Mac, Amiga. C source archive pmars07s.tar.Z - same as above pmars07.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) [ToC] _________________________________________________________________ I do not have FTP. How do I get all this great stuff? 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. [ToC] _________________________________________________________________ I do not have access to Usenet. How do I post and receive news? To receive rec.games.corewar articles by email, join the COREWAR-L list run on the Stormking.Com list processor. To join, send the message 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. [ToC] _________________________________________________________________ Are there any Core War related WWW sites? You bet. Each of the two KotH sites sport a world-wide web server. Stormking's Core War page is ; pizza's is . A third WWW site is in Koeln, Germany: . Last but not least, Stephen Beitzel's "Unofficial Core War Page" is . All site are in varying stages of construction, so it would be futile to list here what they have to offer. [ToC] _________________________________________________________________ When is the next tournament? 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 and other types of tournaments are held frequently among readers of the newsgroup; watch there for announcements or contact me. [ToC] _________________________________________________________________ What is KotH? How do I enter? 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 (warrior) with special comment lines. You will receive a reply indicating how well your program did against the current top programs "on the hill". There are two styles of KotH tournaments, "classical" and "multi-warrior". The "classical" KotH is a one-on-one tournament, that is your warrior 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. In "multi-warrior" KotH, all warriors on the hill fight each other at the same time. Score calculation is a bit more complex than for the one-on-one tournament. Briefly, points are awarded based on how many warriors survive until the end of a round. A warrior that survives by itself gets more points than a warrior that survives together with other warriors. Points are calculated from the formula (W*W-1)/S, where W is the total number of warriors and S the number of surviving warriors. The pMARS documentation has more information on multi-warrior scoring. The idea for an email-based Core War server came from David Lee. The original KotH was developed and run by William Shubert at Intel starting in 1991, 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). Up until May '95, the two sites provided overlapping services, i.e. the some of the hill types were offered by both "pizza" and "stormking". To conserve resources, the different hill types are now divided up among the sites. The way you submit warriors to both KotHs is pretty much the same. Therefore, the entry rules described below apply to both "pizza" and "stormking" unless otherwise noted. 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" (or ";redcode-94, etc., see below) 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 seven separate hills you can select by starting your program with ;redcode-b, ;redcode-94, ;redcode-94x, ;redcode, ;redcode-icws, ;redcode-94m or ;redcode-94xm. The former three run at "pizza", the latter four at "stormking". 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 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 you should get more mail telling you how your program performed against the current top 20 (or 10) 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") hillsize: 20 warriors rounds: 100 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") hillsize: 20 warriors rounds: 100 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'94 Draft Hill Specs: (Accessed with ";redcode-94", available at "pizza") hillsize: 20 warriors rounds: 100 coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: extended ICWS '94 Draft ICWS'94 Beginner's Hill Specs: (Accessed with ";redcode-b", available at "pizza") hillsize: 20 warriors rounds: 100 coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: extended ICWS '94 Draft max. age: after 100 successful challenges, warriors are retired. ICWS'94 Experimental (Big) Hill Specs: (Accessed with ";redcode-94x", available at "pizza") hillsize: 20 warriors rounds: 100 coresize: 55440 max. processes: 10000 duration: after 500,000 cycles, a tie is declared. max. entry length: 200 minimum distance: 200 instruction set: extended ICWS '94 Draft ICWS'94 Draft Multi-Warrior Hill Specs: (Accessed with ";redcode-94m", available at "stormking") hillsize: 10 warriors rounds: 200 coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: extended ICWS '94 Draft ICWS'94 Experimental (Big) Multi-Warrior Hill Specs: (Accessed with ";redcode-94xm", available at "stormking") hillsize: 20 warriors rounds: 100 coresize: 55440 max. processes: 10000 duration: after 500,000 cycles, a tie is declared. max. entry length: 200 minimum distance: 200 instruction set: extended 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. At stormking, a message body with ";help" will return brief instructions. If you submit code containing a ";test" line, your warrior will be assembled but not actually pitted against the warriors on the hill. All hills run portable MARS (pMARS) version 0.7, a platform-independent corewar system available at ftp.csua.berkeley.edu. 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 [ToC] _________________________________________________________________ Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 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. [ToC] _________________________________________________________________ How does SLT (Skip if Less Than) work? 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. [ToC] _________________________________________________________________ What is the difference between in-register and in-memory evaluation? These terms refer to the way instruction operands are evaluated. The '88 Redcode standard ICWS'88 is unclear about whether a simulator should "buffer" the result of A-operand evaluation before the B-operand is evaluated. Simulators that do buffer are said to use in-register evaluation, those that don't, in-memory evaluation. ICWS'94 clears this confusion by mandating in-register evaluation. Instructions that execute differently under these two forms of evaluation are MOV, ADD, SUB, MUL, DIV and MOD where the effective address of the A-operand is modified by evaluation of the B-operand. This is best illustrated by an example: L1 mov b, mov.i #0,impsize 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, mov.i #0,impsize Mirror see reflection. On-axis/off-axis On-axis scanners compare two locations M/2 apart, where M is the memory size. Off-axis scanners use some other separation. Optimal Constants (also optima-type constants) Bomb or scan increments chosen to cover core most effectively, i.e. leaving gaps of uniform size. Programs to calculate optimal constants and lists of optimal numbers are available at ftp.csua.berkeley.edu. Paper A Paper-like program. One which replicates itself many times. Part of the Scissors (beats) Paper (beats) Stone (beats Scissors) analogy. Pit-Trapper (also Slaver, Vampire). A program which enslaves another. Usually accomplished by bombing with JMPs to a SPL 0 pit with an optional core-clear routine. Quick Scan 2c scan of a set group of core locations with bombing if anything is found. Both of the following codes snips scan 16 locations and check for a find. If anything is found, it is attacked, otherwise 16 more locations are scanned. Example: start s1 for 8 ;'88 scan cmp start+100*s1, start+100*s1+4000 ;check two locations mov #start+100*s1-found, found ;they differ so set pointer rof jmn attack, found ;if we have something, get it s2 for 8 cmp start+100*(s2+6), start+100*(s2+6)+4000 mov #start+100*(s2+6)-found, found rof found jmz moveme, #0 ;skip attack if qscan found nothing attack cmp @found, start-1 ;does found points to empty space? add #4000, found ;no, so point to correct location mov start-1, @found ;move a bomb moveme jmp 0, 0 In ICWS'94, the quick scan code is more compact because of the SNE opcode: start ;'94 scan s1 for 4 sne start+400*s1, start+400*s1+100 ;check two locations seq start+400*s1+200, start+400*s1+300 ;check two locations mov #start+400*s1-found, found ;they differ so set pointer rof jmn which, found ;if we have something, get it s2 for 4 sne start+400*(s2+4), start+400*(s2+4)+100 seq start+400*(s2+4)+200, start+400*(s2+4)+300 mov #start+400*(s2+4)-found-100, found rof found jmz moveme, #0 ;skip attack if qscan found nothing add #100, -1 ;increment pointer till we get the which jmn -1, @found ;right place mov start-1, @found ;move a bomb moveme jmp 0, 0 Reflection Copy of a program or program part, positioned to make the active program invisible to a CMP-scanner. Replicator Generic for Paper. A program which makes many copies of itself, each copy also making copies. Self-Splitting Strategy of amplifying the number of processes executing a piece of code. example SPL 0 loop ADD #10, example MOV example, @example JMP loop Scanner A program which searches through core for an opponent rather than bombing blindly. Scissors A program designed to beat replicators, usually a (B-field scanning) vampire. Part of the Paper-Scissors-Stone analogy. Self-Repair Ability of a program to fix it's own code after attack. Silk A replicator which splits off a process to each new copy before actually copying the code. This allows it to replicate extremely quickly. This technique is only possible under the '94 draft, because it requires post-increment indirect addressing. Example: spl 1 mov.i -1, 0 spl 1 ;generate 6 consecutive processes silk spl 3620, #0 ;split to new copy mov.i >-1, }-1 ;copy self to new location mov.i bomb, >2000 ;linear bombing mov.i bomb, }2042 ;A-indirect bombing for anti-vamp jmp silk, {silk ;reset source pointer, make new copy bomb dat.f >2667, >5334 ;anti-imp bomb Slaver see Pit-Trapper. Stealth Property of programs, or program parts, which are invisible to scanners, accomplished by using zero B-fields and reflections. Stone A Stone-like program designed to be a small bomber. Part of the Paper-Scissors-Stone analogy. Stun A type of bomb which makes the opponent multiply useless processes, thus slowing it down. Example is referred to as a spl-jmp bomb. example spl 0 jmp -1 Two-Pass Core-Clear (also spl/dat Core-Clear) core clear that fills core first with SPL instructions, then with DATs. This is very effective in killing paper and certain imp-spiral variations. Vampire see Pit-Trapper. Vector Launch one of several means to start an imp-spiral running. As fast as Binary Launch, but requiring much less code. See also JMP/ADD Launch and Binary Launch. This example is one form of a Vector Launch: impsize equ 2667 example spl 1 ; extend by adding more spl 1's spl 1 djn.a @imp,#0 ; jmp @ a series of pointers dat #0,imp+(3*impsize) dat #0,imp+(2*impsize) dat #0,imp+(1*impsize) dat #0,imp+(0*impsize) imp mov.i #0,impsize [ToC] _________________________________________________________________ Other questions? Just ask in the rec.games.corewar newsgroup or contact me (address below). If you are shy, check out the Core War archives first to see if your question has been answered before. [ToC] _________________________________________________________________ Credits Additions, corrections, etc. to this document are solicited. Thanks in particular to the following people who have contributed major portions of this document: Paul Kline, Randy Graham. Mark Durham wrote the first version of the FAQ. The rec.games.corewar FAQ is Copyright 1995 and maintained by: Stefan Strack, PhD stst@vuse.vanderbilt.edu Institute for Developmental Neuroscience stst@idnsun.gpct.vanderbilt.edu Box 152 GPC stracks@vuctrvax.bitnet Vanderbilt University Voice: +615-343-0238 Nashville, TN 37203, USA FAX: +615-343-0242 _________________________________________________________________ $Id: corewar-faq.html,v 3.2 1995/05/22 03:10:41 stst Exp stst $ From: jls20@hermes.cam.ac.uk (Jon Skeet) Subject: New core war system Date: 1995/06/10 Message-ID: <3rd3pk$qrh@lyra.csx.cam.ac.uk>#1/1 newsgroups: rec.games.corewar I'm about to start writing a new core war system, initially for DOS or LINUX but hopefully portable except graphics routines. I haven't run core war before, but I've just about picked up the basics from the FAQ and a few other sources. What I want to know is, are there any features which you (being more experienced than me) would like included? At the moment, my plan is that once the warrior is assembled (a friend is writing the assembler - I'll pass on any relevant comments) it will display the core in a VGA mode, with 2x2 blocks representing each location in core. The colour of the block will depend on the warrior who last accessed it, and the time since it was last written to or executed (the colours will fade). At the bottom of the screen will be a small bunch of stats - warriors' names, and a bar chart showing how many processes they are running. Also, there may be a birth/death rate for each warrior. Any other ideas? Email me at jls20@hermes.cam.ac.uk if you don't want the rest of the group to be bothered with it. When the system's written I'll post details on how to get it. Jon Skeet From: graham@harlie.mathcs.rhodes.edu (Randy Graham) Subject: Non Plussed Date: 1995/06/12 Message-ID: <1995Jun12.210647.2782@rhodes> newsgroups: rec.games.corewar Well, here is the first successful warrior from me since Comp-Hunter and Strahd fell off the '94 hill. I played with a stone for a while, came up with something good enough to sit in the middle of the beginner's hill, added Blue Funk's imp launch to jump to the top five, then tweaked offsets and added a single-pass core-clear to jump on top of the beginner's hill. Still couldn't make it on the '94 hill though. At this point, I had Unimpspired (when you see the stone, you'll see why I say the stone is uninspired - it is pretty simple, and actaully I didn't think it would be too effective). Well, I didn't feel I could take it any further as is, so I twiddled more, changed the core clear to run forward and add as it goes. Thus, each core location gets dat-bombed and then added to, just in case. In addition, the djn-stream was running backward, trying to unbalance anything that figured its way past the core-clear. The djn-stream actually ended up running almost twice through core by the time it was finished. After the clear hit its djn spot, it ran again, and enough processes had built up to almost finish off core before it completely died (did I mention it was a self-destruct core-clear - thanks to Aeka for that idea - its done its job, now get out of the way). So, since the imp couldn't live through the forward core clear, I had to go to something else to keep myself alive after the stone started dying - obviously a job silk paper (thanks to J. Pohlsdrihjs-something ;-) for the silk paper idea). So, here he is so far - Non Plussed. Note that if you run him, you will find he actually dies if a round runs long enough. He actully has about 100 processes left when time runs out in an 80000 cycle, single test run. I need to tweak some more to get a good stone step size. And of course, the whole point of adding the paper was to be alive after the core clear, so I have to work on keeping that alive. However, I think he is good learning material for a new person. In fact, one of the things I like about Non Plussed is how he can keep throwing memory around and keep up with the rabbit-like paper. Two spl in front of the stone explain the basic method - I first saw it in Blue Funk I believe. However, I found that the stone didn't quite live long enough to go into its core-clear. So, notice what he does after launching his first paper child. He splits to the stone, thus giving an extra round of stoning in the middle of canvassing the area. Anyway, sorry this took so long to get here, but I wanted to explain my thought process. So, here he is, as on the current hills, but with room for improvement.............. ------------------------------------------------------------ ;redcode-94 ;name Non Plussed ;kill Non Plussed ;author Randy Graham ;assert 1 ;strategy A moderate stone with self-destruct forward dat and ;strategy addition core-clear and djn stream twice through core. ;strategy Added paper since imp-ring gets blasted by forward clear. STONE equ (begin+1472) ;where to move the stone SSTEP equ 28 ;step size for stone PAPEROFF equ 1495 ;paper step size - still needs tweaking begin mov.i stopp, }STONE-SSTEP+1 ;extra guys into the stone stopp dat.f >paper, STONE keepup spl.a #0, <-SSTEP-1 sbegin spl.a #SSTEP, <-SSTEP stoner mov.i <-1-SSTEP, >1+SSTEP sub.f sbegin, -1 djn.f stoner, <-381 mover mov.i 3, >1 paper spl.a @0, PAPEROFF movpapr mov.i }paper, >paper getimp mov.i nonimp, >-550 novamp mov.i static, }400 again spl.a paper, {paper incr dat.f >getimp+(3*PAPEROFF),>novamp+(2*PAPEROFF) ;increment correct childrens imp bombs and vamp bombs nonimp dat.f <2667, <5334 static dat.f >1, >1 ;add blank lines to make me look long in a combat report for MAXLENGTH-CURLINE dat.f 0, 0 rof From: davidlee@central.bldrdoc.gov (David Lee) Subject: C++Robots: Graphical Trace Interpreter? Date: 1995/06/12 Message-ID: #1/1 newsgroups: rec.games.corewar I've seen a graphics (ASCII text) display of real-time robot battles in the CROBOTS package, but do you know of such a display routine that might accept the traces that are mailed back from the PBeM server? And then display the action slice by slice? Thanks, David From: MB Subject: Wanted: FAQ Date: 1995/06/12 Message-ID: #1/1 newsgroups: rec.games.corewar :-) Morten Brodersen ------------------------------------------------------------ Morten Brodersen email: morten.brodersen@copenhagen.attgis.com From: Martin Maierhofer Subject: Re: New core war system Date: 1995/06/12 Message-ID: <3rhd09$a59@news.tuwien.ac.at>#1/1 references: <3rd3pk$qrh@lyra.csx.cam.ac.uk> <3rh1qn$gqb@lyra.csx.cam.ac.uk> newsgroups: rec.games.corewar jls20@hermes.cam.ac.uk (Jon Skeet) wrote: [...] > >Well, I'll have a go, but it'll probably be October before I can get >it to y'all... I don't have network connections or a Linux machine at >home, so I'll be stuck over the long vac. Does anyone here know how >easy it is to communicate with pMARS? Will it output data to a named >pipe that I then just do a graphics display from, or will I need to go >into the pmars code itself? > >I've checked out the Linux SVGA version of pmars, and really hated it >- I don't know whether it was that I hadn't configured it properly or >something, but it really looked ugly. I'm gonna check out the DOS >version today, but if it's similar to the Linux version, and you think >it's pretty... well, you ain't seen nothin' yet! Admittedly knowing my >slowness of coding you won't see anything from me for a while, but >hopefully it'll be good when it comes. > I'm the one who wrote (haha !) the SVGA version (in fact, I only converted the DOS graphical routines to the ones provided by the Linux SVGA library, added some keyboard and mouse handling). Though I haven't seen the DOS version (don't use it anymore ;-) I'm pretty sure it will look about the same. Personally, I don't think the interface of pMARS is too bad, but that's of course a matter of taste... BTW, there's not much of a 'configuration' -- the only thing you can do is to change the resolution of the screen. [...] >>> comments) it will display the core in a VGA mode, with 2x2 blocks >>> representing each location in core. The colour of the block will >>> depend on the warrior who last accessed it, and the time since it was >>> last written to or executed (the colours will fade). Except for the fading colours (nice idea indeed !), I don't see much difference in the *concept* of the pMARS display and yours -- of course I can't say anything about the look of your version as of now... >>> At the bottom of >>> the screen will be a small bunch of stats - warriors' names, and a bar >>> chart showing how many processes they are running. Also, there may be >>> a birth/death rate for each warrior. pMARS has it at the top of the screen - the debugger occupies the area below the core display. [...] > >Jon Skeet > The thing I had in mind when I started working on the Linux SVGA version was that I didn't want to switch to DOS to get a graphical version of pMARS up and running (I don't like curses too much...) I did not want to create a new interface to pMARS but decided to stick to the DOS version (of course it was *a lot* easier to adapt the DOS display code than to write all of the code from scratch). Another reason for sticking to the DOS version was the 'p' in pMARS: although the display code for various machines/graphics libraries can't be 'portable' as such, the user interface can and I think all of the version of pMARS should behave at least 'similar' in terms of the UI. martin PS: I'd like to give Jon's corewar system a try once it's available... -- Martin Maierhofer | "History will teach us nothing." m.maierhofer@ieee.org | - Sting e9125110@student.tuwien.ac.at --- http://stud1.tuwien.ac.at/~e9125110 From: jls20@hermes.cam.ac.uk (Jon Skeet) Subject: Re: New core war system Date: 1995/06/12 Message-ID: <3rh1qn$gqb@lyra.csx.cam.ac.uk>#1/1 references: <3rd3pk$qrh@lyra.csx.cam.ac.uk> newsgroups: rec.games.corewar In article , Jay "Thierry" Han wrote: >jls20@hermes.cam.ac.uk (Jon Skeet) writes: > >> I'm about to start writing a new core war system, initially for DOS or >> LINUX but hopefully portable except graphics routines. > >Hey, why don't you make an X-window version while you're at it? That >would be beneficial for all of us. There is already an excellent DOS >version (pMARS). We're all hoping someone volunteers to write an X >graphic output for pMARS... Well, I'll have a go, but it'll probably be October before I can get it to y'all... I don't have network connections or a Linux machine at home, so I'll be stuck over the long vac. Does anyone here know how easy it is to communicate with pMARS? Will it output data to a named pipe that I then just do a graphics display from, or will I need to go into the pmars code itself? I've checked out the Linux SVGA version of pmars, and really hated it - I don't know whether it was that I hadn't configured it properly or something, but it really looked ugly. I'm gonna check out the DOS version today, but if it's similar to the Linux version, and you think it's pretty... well, you ain't seen nothin' yet! Admittedly knowing my slowness of coding you won't see anything from me for a while, but hopefully it'll be good when it comes. >> I haven't run >> core war before, but I've just about picked up the basics from the FAQ >> and a few other sources. What I want to know is, are there any >> features which you (being more experienced than me) would like >> included? At the moment, my plan is that once the warrior is assembled >> (a friend is writing the assembler - I'll pass on any relevant >> comments) it will display the core in a VGA mode, with 2x2 blocks >> representing each location in core. The colour of the block will >> depend on the warrior who last accessed it, and the time since it was >> last written to or executed (the colours will fade). > ^^^^^^^^^^^^^^^^^^^^^ >That's neat. Thanks! >> At the bottom of >> the screen will be a small bunch of stats - warriors' names, and a bar >> chart showing how many processes they are running. Also, there may be >> a birth/death rate for each warrior. >> >> Any other ideas? Email me at jls20@hermes.cam.ac.uk if you don't want >> the rest of the group to be bothered with it. When the system's >> written I'll post details on how to get it. > >I think the single most useful part of pMARS is its debugger. Any >visual corewar system should at least allow to look at code and >single-step, otherwise it's just a colorful bunch of dots. Okay - good point, I hadn't thought of that. Shouldn't be too hard to do - I'll see how pmars does it and see what I can do. Thanks for the help, Jon Skeet From: KOTH Tourney Server Subject: SKI-ICWS: Status - Multiwarrior Experimental 94 Date: 1995/06/12 Message-ID: <199506120400.AAA23557@valhalla.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status See up to the seconds scores at http://www.stormking.com/~koth Current Status of the StormKing Industries MultiWarrior Experimental 94 CoreWar Hill: # Name Author Score Age 1 TimeScapeX (0.1) J. Pohjalainen 8449 10 2 life Nandor Sieben 6870 11 3 Lucky 13 Stefan Strack 6531 12 4 Ochre Jelly v1.1 Brian Zellner 6128 4 5 Shwing! T. H. Davies 5630 6 6 AB Scanner 2.8.1 Chris Hodson 3953 8 7 Agilulfo 1.1 Beppe Bezzi 1680 2 8 Veeble Jr. T. H. Davies 1669 7 9 Bloody! G. Eadon 1656 3 10 MuDwarf G. Eadon 1198 1 11 Ochre Jelly v1.0 Brian Zellner 0 5 12 AB Scanner 2.8 Chris Hodson 0 9 13 None Nobody 0 13 14 None Nobody 0 13 15 None Nobody 0 13 16 None Nobody 0 13 17 None Nobody 0 13 18 None Nobody 0 13 19 None Nobody 0 13 20 None Nobody 0 13 21 None Nobody 0 13 From: KOTH Tourney Server Subject: SKI-ICWS: Status - MultiWarrior 94 Date: 1995/06/12 Message-ID: <199506120400.AAA19452@valhalla.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status See up to the seconds scores at http://www.stormking.com/~koth Current Status of the StormKing Industries Multiwarrior 94 CoreWar Hill: # Name Author Score Age 1 Christmas Tie P.Kline 3093 28 2 nobody special Mike Nonemacher 2789 35 3 TimeScape (1.1) J. Pohjalainen 2780 18 4 B-Panama X Steven Morrell 2673 2 5 Paper Dreaming P.Kline 2311 36 6 Ochre Jelly v1.1 Brian Zellner 2245 1 7 life Nandor Sieben 2185 37 8 Vanilla 1.3 Robert Macrae 1938 40 9 Shwing! T. H. Davies 1755 12 10 Keystone P.Kline 1658 39 11 Agilulfo 1.1 Beppe Bezzi 338 0 From: KOTH Tourney Server Subject: SKI-ICWS: Status - Standard Date: 1995/06/12 Message-ID: <199506120400.AAA36335@valhalla.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status See up to the seconds scores at http://www.stormking.com/~koth Current Status of the StormKing Industries Standard KotH CoreWar Hill : # %W/ %L/ %T Name Author Score Age 1 33/ 16/ 50 Cannonade P.Kline 151 51 2 32/ 18/ 51 ttti nandor sieben 145 1 3 33/ 21/ 46 Blue Funk 88 Steven Morrell 144 15 4 31/ 19/ 49 Peace Mr. Jones 143 25 5 28/ 14/ 58 Imps! Imps! Imps! Steven Morrell 141 62 6 33/ 25/ 42 Test Wayne Sheppard 141 40 7 47/ 53/ 0 Unknown Wolfgang Weisser 141 12 8 34/ 27/ 39 Smoke v1.3a Brian Zellner 141 13 9 43/ 46/ 11 bigproba nandor sieben 140 39 10 31/ 23/ 46 CAPS KEY IS STUCK AGAIN Steven Morrell 139 17 11 39/ 39/ 23 Christopher Steven Morrell 139 16 12 40/ 45/ 14 Iron Gate Wayne Sheppard 135 145 13 37/ 38/ 25 Keystone t21 P.Kline 135 38 14 38/ 41/ 21 Beholder's Eye V1.7 W. Mintardjo 134 95 15 36/ 38/ 25 .T.E.S.T. V0.1 P.E.M & E.C 134 48 16 31/ 27/ 42 Der Zweiter Blitzkrieg Mike Nonemacher 134 46 17 40/ 47/ 13 Dagger v4.1 Michael Constant 134 60 18 30/ 27/ 44 Hydra Stephen Linhart 132 125 19 35/ 44/ 21 Titled Steven Morrell 127 14 20 35/ 46/ 20 Summer Kitten Richard van der Brug 124 41 21 24/ 74/ 2 gen5.150 mate_mod v1.1 75 0 From: KOTH Tourney Server Subject: SKI-ICWS: Status - ICWS Tournament Date: 1995/06/12 Message-ID: <199506120400.AAA21491@valhalla.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status See up to the seconds scores at http://www.stormking.com/~koth Current Status of the StormKing Industries Annual ICWS Tournament CoreWar Hill: # %W/ %L/ %T Name Author Score Age 1 60/ 7/ 33 Cannonade Paul Kline 213 24 2 67/ 25/ 8 Agony T Stefan Strack 209 25 3 52/ 40/ 9 xtc stefan roettger 163 29 4 50/ 40/ 10 Smartbomb 4.0 Devin Kilminster 159 22 5 48/ 42/ 10 Smartbomb 4.0 Devin Kilminster 155 23 6 48/ 42/ 11 Cat v2.0 Tim Scheer 154 21 7 46/ 38/ 16 scissors matthew householder 153 39 8 44/ 41/ 16 stone matthew householder 146 36 9 43/ 41/ 16 Smart Bomb 2.2 Devin Kilminster 145 26 10 43/ 47/ 9 Irony v1.0 Brant D. Thomsen 139 28 11 39/ 47/ 14 warrior 42 stefan roettger 130 37 12 35/ 42/ 23 Arschkarte V2.0 Thomas Nitsche 128 1 13 30/ 35/ 36 Logan John Lewis 125 6 14 37/ 52/ 11 doublestorm ii matthew j. chung 122 33 15 30/ 39/ 31 Intangible Dwarf 88.3 Campbell Fraser 121 27 16 28/ 40/ 33 Impetus v1.0 Michael Constant 116 19 17 32/ 49/ 19 Trap v0.6 Wolfgang Weisser 114 3 18 27/ 40/ 33 Impetus v1.0 Michael Constant 114 20 19 32/ 51/ 17 Trap v0.6a Wolfgang Weisser 113 2 20 29/ 46/ 25 paper: a.k.a molerat scott nelson 112 30 21 21/ 34/ 44 Flatline4 Thomas Nitsche 108 13 From: han@imag.fr (Jay "Thierry" Han) Subject: Re: New core war system Date: 1995/06/12 Message-ID: #1/1 references: <3rd3pk$qrh@lyra.csx.cam.ac.uk> newsgroups: rec.games.corewar In article <3rd3pk$qrh@lyra.csx.cam.ac.uk> jls20@hermes.cam.ac.uk (Jon Skeet) writes: > I'm about to start writing a new core war system, initially for DOS or > LINUX but hopefully portable except graphics routines. Hey, why don't you make an X-window version while you're at it? That would be beneficial for all of us. There is already an excellent DOS version (pMARS). We're all hoping someone volunteers to write an X graphic output for pMARS... > I haven't run > core war before, but I've just about picked up the basics from the FAQ > and a few other sources. What I want to know is, are there any > features which you (being more experienced than me) would like > included? At the moment, my plan is that once the warrior is assembled > (a friend is writing the assembler - I'll pass on any relevant > comments) it will display the core in a VGA mode, with 2x2 blocks > representing each location in core. The colour of the block will > depend on the warrior who last accessed it, and the time since it was > last written to or executed (the colours will fade). ^^^^^^^^^^^^^^^^^^^^^ That's neat. > At the bottom of > the screen will be a small bunch of stats - warriors' names, and a bar > chart showing how many processes they are running. Also, there may be > a birth/death rate for each warrior. > > Any other ideas? Email me at jls20@hermes.cam.ac.uk if you don't want > the rest of the group to be bothered with it. When the system's > written I'll post details on how to get it. I think the single most useful part of pMARS is its debugger. Any visual corewar system should at least allow to look at code and single-step, otherwise it's just a colorful bunch of dots. > > Jon Skeet Good luck anyway, -=< Jay "Thierry" Han >=- Jay.Han@imag.fr Bull-IMAG/Systemes. 2, av. Vignate. ZI Mayencin II, 38610 Gieres. Tel: +33 76.63.48.41. Fax: 76.54.76.15. Perso: 61, rue Thiers. 38000 Grenoble. 76.46.11.26. From: jlewisos@aol.com (JLewisOS) Subject: Revolutionary Redcode Changes Date: 1995/06/14 Message-ID: <3rnism$b4u@newsbf02.news.aol.com>#1/1 newsgroups: rec.games.corewar There are three changes to the standard I would like to start debate on. I would prefer that the changes be considered as a whole, rather than piecemeal. The combination of the three changes would bring Core Wars to a new level and I ask that you think about the results of the proposed changes to the way in which code is written. When considering the changes ask yourself these questions: Would I enjoy writing this version of redcode more or less? What new strategies could be used, what old ones would become obsolete? What behavior would this type of standard create in the warriors? The first change is in the way a program is determined to be "dead". I propose that if any of the programs processes fail to execute then the program should be considered dead. (This would require the creation of a new command to "end" a process without executing an illegal command.) The second change is that all possesses execute "simultaneously". Each program would execute all of it's processes in a batch (in order of creation). The third change is perhaps the most radical, allowing programs to access the higher functions of MARS. Giving programs limited access to process pointers, que lists, and coresize would naturally produce varied strategies for eliminating an opponent. I am very interested in creating a debate on these proposed changes and listening to the concerns of players. John Lewis JLewisOS.@aol.com From: graham@harlie.mathcs.rhodes.edu (Randy Graham) Subject: Vamp Stone? Date: 1995/06/14 Message-ID: <1995Jun14.132215.2783@rhodes>#1/1 newsgroups: rec.games.corewar In the "Well, it seemed like a good idea..." category, we have building blocks. Here was my thinking on this: What is the biggest cause of vampires loosing to paper? Too stinkin' many process for the pit to catch them all before a sweep. How can we solve this? Well, let them sit a while in the pit before sweeping. But how do do this without putting oneself in the pit, still bombing all of core at a good step (mod-4 for most vamps, I think), don't get so big that scanners find you easily, and still be reasonably quick? My thought was, have a stone and a vampire working together. That next to last site the stone hits is the fang thrower. This stops the vampire just before he hits the stone and himself, therefore not jumping in the pit with the enemy. Then, have the stone sweep core, hitting the pit just before hitting itself, leaving only one spl #0 line. Unfortunately, this didn't work with my first test. Here is builing blocks as I first threw him together. Maybe incorporating a two-pass clear would work, but if you're going to two pass clear, you probably don't need the help of the vamp anyway. If anyone can improve her, let me know (scores about 95 on the '94 hill). Randy ------------------------------------------------------------ ;redcode-94 ;name Building Blocks ;kill Building Blocks ;author Randy Graham ;assert 1 ;strategy Stone from Non Plussed and a simple vampire working together. STONE equ (stoneup+1472) ;where to move the stone VAMPOFF equ (STONE+VSTEP-1) ;where to move the vampire PITOFF equ (VAMPOFF+DIFF) ;where to put the pit SSTEP equ 36 ;step size for stone VSTEP equ 108 ;step size for fangs WHICH equ (1) ;which line off the stone to bomb (well = 0) TRAP equ (DIFF+3) ;where the fang is DIFF equ (35) ;how far past vamp to put pit org stoneup stoneup mov.i WHICH+SSTEP sub.f well, -1 djn.f stoner, <-381 mover mov.i 3, {1 vamp spl.a #VSTEP, <-VSTEP fanger mov.i TRAP-2, @TRAP-2 sub.f vamp, fanger+TRAP-2 djn.f fanger, <-381 pit spl.a #0, <-12 jmp.a -1, <-12 fang jmp.a pit+TRAP-3-VSTEP, 0-TRAP+3+VSTEP ;for MAXLENGTH-CURLINE ; dat.f 0, 0 ;rof end stoneup From: jlewisos@aol.com (JLewisOS) Subject: Re: Revolutionary Redcode Changes Date: 1995/06/15 Message-ID: <3rq6e9$1fo@newsbf02.news.aol.com>#1/1 references: <3rov9f$n3d@lyra.csx.cam.ac.uk> newsgroups: rec.games.corewar >But what if two processes try to change or read the same location? >When would it be read? Whose process should take precedence? Also, it >would be a pain to include in the system, I suspect :) It's the same as it is now. The processes act in the order they are created, with new porcesses starting on the next cycle. All of your existing processes would execute, then all your opponents. Would be a relativly minor change if I understand MARS correctly. John- From: graham@harlie.mathcs.rhodes.edu (Randy Graham) Subject: Re: Revolutionary Redcode Changes Date: 1995/06/15 Message-ID: <1995Jun15.131414.2785@rhodes>#1/1 references: <3rnism$b4u@newsbf02.news.aol.com> newsgroups: rec.games.corewar JLewisOS (jlewisos@aol.com) wrote: : There are three changes to the standard I would like to start debate on. Good, debate (discussion) is good. : I would prefer that the changes be considered as a whole, rather than : piecemeal. The combination of the three changes would bring Core Wars to : a new level and I ask that you think about the results of the proposed : changes to the way in which code is written. When considering the changes : ask yourself these questions: : Would I enjoy writing this version of redcode more or less? No thanks, but others may want to (see comment below) : What new strategies could be used, what old ones would become obsolete? Stones would be even more popular. Silk paper and probably imp ring would go away. : What behavior would this type of standard create in the warriors? Again, stones would probably lead the pack in strength then. : The first change is in the way a program is determined to be "dead". I : propose that if any of the programs processes fail to execute then the : program should be considered dead. (This would require the creation of a : new command to "end" a process without executing an illegal command.) I don't care much for this one. The benefit of multi-processing is lost almost immediately. In fact, extra "selves" becomes a detriment. If I right a stone the is four lines long, I cover core in a few thousand cycles. If I last long enough to make this sweep of core, only programs of length 1, 2, or 3 can survive without a hit. Now, normally a paper can survive this hit because of all its bodies. However, with this change, the paper will be dead because some part of it almost has to have been hit in this time. Also, the benefit of gate-crashing imp-spirals goes, since usually, sometime along the way, one of the parts of the spiral "dies," but since there are other processes following, they can continue on. With your new method, the whole imp is dead. I imagine if this change were implemented, I could win a lot of combats with this warrior: mov.i 2, <1 jmp.a -1, <-1 I would be very hard to find, and in ~16000 cycles, I would have swept core. Unless a warrior used pickets and moved itself, the battle would be over before I wiped myself out. : The second change is that all possesses execute "simultaneously". Each : program would execute all of it's processes in a batch (in order of : creation). How could we tell then who gets credit for hitting a spot. Suppose I drop an spl bomb on a stone at the same time it self-modifies and moves its sweep line in place. Who gets that location? : The third change is perhaps the most radical, allowing programs to access : the higher functions of MARS. Giving programs limited access to process : pointers, que lists, and coresize would naturally produce varied : strategies for eliminating an opponent. Well, unfortunately warriors already have access to coresize. In the original paper on CoreWar (by A.K. Dewdney), nothing was known about core. With the latest pMars, CoreSize, # of Cycles, and a few other things can be gotten. I'm not sure how much this has affected the game, but I think it probably reduces the challenge at least a little (especially knowing coresize). : I am very interested in creating a debate on these proposed changes and : listening to the concerns of players. : John Lewis : JLewisOS.@aol.com From: jls20@hermes.cam.ac.uk (Jon Skeet) Subject: Re: Revolutionary Redcode Changes Date: 1995/06/15 Message-ID: <3rov9f$n3d@lyra.csx.cam.ac.uk>#1/1 references: <3rnism$b4u@newsbf02.news.aol.com> newsgroups: rec.games.corewar In article <3rnism$b4u@newsbf02.news.aol.com>, JLewisOS wrote: > >The second change is that all possesses execute "simultaneously". Each >program would execute all of it's processes in a batch (in order of >creation). But what if two processes try to change or read the same location? When would it be read? Whose process should take precedence? Also, it would be a pain to include in the system, I suspect :) >The third change is perhaps the most radical, allowing programs to access >the higher functions of MARS. Giving programs limited access to process >pointers, que lists, and coresize would naturally produce varied >strategies for eliminating an opponent. I'm only a beginner to Redcode, but what I find attractive about it is the simplicity of it. The machine itself is transparent - it doesn't matter how instructions are numbered, etc (ie in some systems DAT may be represented as a 0 in the code, in some it may be something else). It seems like the ultimately portable code - there is basically no architecture involved. I'm in favour of keeping this part the way it is. Jon "Trying to get a fast fade" Skeet From: Stephen Mosen Subject: Example programs... Date: 1995/06/16 Message-ID: #1/1 newsgroups: rec.games.corewar Does anyone have some simple redcode programs that I could have a look at to get me started? I have read all the FAQs I could find (and the icws94 draft) but what I really need is examples for each of the opcodes available. I have thought of some (good?) strategies but don't yet know how to impliment them... Any helpful hints would also be greatly appreciated I have already submitted a couple of warriors to the beginners hill but I could really do with seeing how other people are constructing their programs. Please e-mail... Thanks in advance -------------------------------------------------------------------- Stephen Mosen Wellington, New Zealand From: sieben@imap1.asu.edu Subject: Re: Revolutionary Redcode Changes Date: 1995/06/16 Message-ID: <3rqou9$sa6@news.asu.edu>#1/1 references: <3rnism$b4u@newsbf02.news.aol.com> newsgroups: rec.games.corewar : The first change is in the way a program is determined to be "dead". I : propose that if any of the programs processes fail to execute then the : program should be considered dead. (This would require the creation of a : new command to "end" a process without executing an illegal command.) This would eliminate replicators. : The second change is that all possesses execute "simultaneously". Each : program would execute all of it's processes in a batch (in order of : creation). I think this is way too powerful. I understand that we something like this to compensate the first change. But if the processes are at the same location, they not very vulnerable. For example spl 0 mov bomb , <-10 jmp -2 Nandor. From: morrell@jeeves.math.utah.edu (Steven C. Morrell) Subject: Re: Revolutionary Redcode Changes Date: 1995/06/16 Message-ID: #1/1 references: <3rnism$b4u@newsbf02.news.aol.com> <1995Jun15.131414.2785@rhodes> newsgroups: rec.games.corewar In article <1995Jun15.131414.2785@rhodes> graham@harlie.mathcs.rhodes.edu (Randy Graham) writes: JLewisOS (jlewisos@aol.com) wrote: : What new strategies could be used, what old ones would become obsolete? Stones would be even more popular. Silk paper and probably imp ring would go away. Stones? Obsolete against this warrior: for 12 spl 1 rof mov 2,<-1 mov 1,<-2 end Any warrior who can't find and kill me in an average of 13.5 rounds is toast! Imp rings wouldn't survive because you just have to kill the trailing process. And 13.5 rounds hardly gives most programs a chance to start up. So much for variety of warriors! (Just my $.02 worth.) Steven Morrell morrell@math.utah.edu From: steve.mercer@network.com (Steve E. Mercer) Subject: Re: Revolutionary Redcode Changes Date: 1995/06/16 Message-ID: #1/1 references: <3rnism$b4u@newsbf02.news.aol.com> newsgroups: rec.games.corewar In article b4u@newsbf02.news.aol.com, jlewisos@aol.com (JLewisOS) writes: >The first change is in the way a program is determined to be "dead". I >propose that if any of the programs processes fail to execute then the >program should be considered dead. So if I launch an imp, and you stop my imp, then my entire program dies? A single lucky bomb that stops one of my processes will kill my entire program? >The second change is that all possesses execute "simultaneously". Each >program would execute all of it's processes in a batch (in order of >creation). So your program with hundreds of processes gets to execute every one of these processes for each time that my program with only one process gets to execute its single process? >The third change is perhaps the most radical, allowing programs to access >the higher functions of MARS. Giving programs limited access to process >pointers, que lists, and coresize would naturally produce varied >strategies for eliminating an opponent. So you can look at the pointers to locate my program and stop it with a single bomb? In my opinion, implementing these changes could lead to a bad system. Programs would split into as many processes as they could because it costs them nothing and they get great benefit from it. With a lot of processes, saturation bombing or fast core clearing would become extremely effective. I imagine a program like: split, bomb, goto split would quickly become the only viable warrior on a hill. The number of bombs launched per turn increases extremely rapidly, at no cost in execution time to the program. In just a few rounds, this program would have enough processes to bomb every core location in a single turn. Furthermore, it would only have to stop a single one of its opponent's processes to kill its opponent entirely. And if it has access to the process pointers and queue lists, it could know where to start looking for it's opponent. Unless I am missing something obvious, I do not believe that these proposed changes would be a good idea. --- Steve Mercer steve.mercer@network.com From: jlewisos@aol.com (JLewisOS) Subject: Re: Revolutionary Redcode Changes Date: 1995/06/16 Message-ID: <3rsbes$gru@newsbf02.news.aol.com>#1/1 references: <1995Jun15.131414.2785@rhodes> newsgroups: rec.games.corewar <> "*" *"I don't care much for this one. The benefit of multi-processing is lost almost immediately. In fact, extra "selves" becomes a detriment. If I right a stone the is four lines long, I cover core in a few thousand cycles. If I last long enough to make this sweep of core, only programs of length 1, 2, or 3 can survive without a hit. Now, normally a paper can survive this hit because of all its bodies. However, with this change, the paper will be dead because some part of it almost has to have been hit in this time."* Multi-processing benefits would be limited to functionality. One problem now is the games that end with both sides in the thousands of processes. This would almost eliminate the large number of ties in the present draft. The ties come from the large number of enemy processes you need to kill in order to eliminate an opponent and this problem reduces the number of possible strategies. Paper would evolve into smaller number copies, (maybe three processes). Dwarf programs are already defeated by moving you program around the core, I don't see why this would change. *"I imagine if this change were implemented, I could win a lot of combats with this warrior: mov.i 2, <1 jmp.a -1, <-1 I would be very hard to find, and in ~16000 cycles, I would have swept core. Unless a warrior used pickets and moved itself, the battle would be over before I wiped myself out."* Most scanner would find you before that, your trail of altered DAT statements would lead right to you. I have a feeling that what Dewey thought about Mice the first year applies here. New strategies will evolve to combat old ones. *"How could we tell then who gets credit for hitting a spot. Suppose I drop an spl bomb on a stone at the same time it self-modifies and moves its sweep line in place. Who gets that location? "* When I said "simultaneously" it was a bad choice of wording. What I mean is that all the processes for one program are evaluated before evaluating the next program's processes. If your program has eight processes it would evaluate all eight before processing the opponents code. *"Well, unfortunately warriors already have access to coresize. In the original paper on CoreWar (by A.K. Dewdney), nothing was known about core. With the latest pMars, CoreSize, # of Cycles, and a few other things can be gotten. I'm not sure how much this has affected the game, but I think it probably reduces the challenge at least a little (especially knowing coresize)."* I guess I mean it would be interesting to have access to changing some of the parameters of the core. Perhaps it would be possible to change the maximum number of processes, or change core size while running the simulation. I haven't fully envisioned the amount of control a program would have, but I am interested in input about what everyone finds interesting. John Lewis JLewisOS@aol.com From: jlewisos@aol.com (JLewisOS) Subject: Re: Revolutionary Redcode Changes Date: 1995/06/17 Message-ID: <3rv048$67m@newsbf02.news.aol.com>#1/1 references: newsgroups: rec.games.corewar >Stones? Obsolete against this warrior: > >for 12 > spl 1 >rof > >mov 2,<-1 >mov 1,<-2 > >end > >Any warrior who can't find and kill me in an average of 13.5 rounds is >toast! Imp rings wouldn't survive because you just have to kill the >trailing process. And 13.5 rounds hardly gives most programs a chance >to start up. So much for variety of warriors! > >(Just my $.02 worth.) > >Steven Morrell morrell@math.utah.edu sne ~-1,#0 jmp -1,<-2 mov bomb,@-3 Where ~ represents looking into the queue for pointers. Any program that had tons of processes would have to deal with queue scanners. Perhaps a counter would be sending fake pointer to the queue. John - From: jlewisos@aol.com (JLewisOS) Subject: Re: Revolutionary Redcode Changes Date: 1995/06/17 Message-ID: <3ruu46$5n5@newsbf02.news.aol.com>#1/1 references: <3rqou9$sa6@news.asu.edu> newsgroups: rec.games.corewar :: The first change is in the way a program is determined to be "dead". I :: propose that if any of the programs processes fail to execute then the :: program should be considered dead. (This would require the creation of a :: new command to "end" a process without executing an illegal command.) >This would eliminate replicators. It would eliminate replicators as we now know them, I have a feeling that replication would simply take on another form (limited replications for example, where copies killed themselves after producing a single offspring.) :: The second change is that all possesses execute "simultaneously". Each :: program would execute all of it's processes in a batch (in order of :: creation). >I think this is way too powerful. I understand that we something like >this to compensate the first change. But if the processes are at the same >location, they not very vulnerable. >For example > spl 0 > mov bomb , <-10 > jmp -2 > >Nandor. The compensation for this would be the high queue presence for this program, making it extremely vulnerable to queue scanners. John - From: jlewisos@aol.com (JLewisOS) Subject: Re: Revolutionary Redcode Changes Date: 1995/06/17 Message-ID: <3rtscf$qp@newsbf02.news.aol.com>#1/1 references: newsgroups: rec.games.corewar >So if I launch an imp, and you stop my imp, then my entire program dies? >A single lucky bomb that stops one of my processes will kill my entire >program? Yes. (But the term lucky is somewhat misleading.) You would only create a sub program if it was vital to your program. Too many ties are created from: spl 0, >3 jmp -1, >4 and other variations on this theme. >So your program with hundreds of processes gets to execute every one of >these processes for each time that my program with only one process >gets to execute its single process? That's right, that's the bonus for taking on the risk of multiple processes. >So you can look at the pointers to locate my program and stop it with >a single bomb? No. I am still working this part out. What I want is more information for the programs. Most code just rumbles through the core blindly killing anything it stubles into. (Re: Lucky) I want programs that act more intelligently and the only way to get them is to make gathering information cheap (in a time sense). Ideally the best code should seem intelligent when it trashes an opponent but most code just optimizes modifiers or single commands creating "dumb" work warriors. >In my opinion, implementing these changes could lead to a bad system. >Programs would split into as many processes as they could >because it costs them nothing and they get great benefit from it. The cost of creating extra processes is the vulnerability of losing any single process. Perhaps finding a pointer in the queue was proportional to the number of process running. (If you have lots of processes, you are more vulnerable to having someone find your pointer.) >With a lot of processes, saturation bombing or fast core clearing >would become extremely effective. >I imagine a program like: split, bomb, goto split would quickly >become the only viable warrior on a hill. The number of bombs >launched per turn increases extremely rapidly, at no cost in >execution time to the program. In just a few rounds, this program >would have enough processes to bomb every core location in a single >turn. Hmm... You can't quite double processes in a single turn, but if you could have a string of SPL 0 1 2 4 8 16 32 64 128 256 512 1024 2048 4056 8000 ...14 turns to top out your processes. Perhaps a lower process total would be required... something like 128? The pointer queue might have only 128 spaces in it, un-used spaces would give results of dat 0, while actual pointers would give the absolute location of a process... >Furthermore, it would only have to stop a single one of its >opponent's processes to kill its opponent entirely. And if it has >access to the process pointers and queue lists, it could know where >to start looking for it's opponent. I would prefer that the pointer queue list only give a clue as to where the opponent is. No one wants three turn battles. But I think most people will agree that having champion programs that tie more than a third of thier games is odd. John- From: KOTH Tourney Server Subject: SKI-ICWS: Status - MultiWarrior 94 Date: 1995/06/19 Message-ID: <199506190400.AAA16071@valhalla.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status See up to the seconds scores at http://www.stormking.com/~koth Current Status of the StormKing Industries Multiwarrior 94 CoreWar Hill: # Name Author Score Age 1 Christmas Tie P.Kline 3037 31 2 nobody special Mike Nonemacher 2894 38 3 B-Panama X Steven Morrell 2799 5 4 Paper Dreaming P.Kline 2750 39 5 TimeScape (1.1) J. Pohjalainen 2701 21 6 Non Plussed Randy Graham 2485 2 7 life Nandor Sieben 2216 40 8 Shwing! T. H. Davies 1942 15 9 Vanilla 1.3 Robert Macrae 1528 43 10 AB Scanner 2.9 Chris Hodson 1475 1 11 Ochre Jelly v1.1 Brian Zellner 0 4 From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Re: Revolutionary Redcode Changes Date: 1995/06/19 Message-ID: <1995Jun19.192407.2788@rhodes>#1/1 references: newsgroups: rec.games.corewar JLewisOS (jlewisos@aol.com) wrote: : >Stones? Obsolete against this warrior: : > : >for 12 : > spl 1 : >rof : > : >mov 2,<-1 : >mov 1,<-2 : > : >end : > : >Any warrior who can't find and kill me in an average of 13.5 rounds is : >toast! Imp rings wouldn't survive because you just have to kill the : >trailing process. And 13.5 rounds hardly gives most programs a chance : >to start up. So much for variety of warriors! : > : >(Just my $.02 worth.) : > : >Steven Morrell morrell@math.utah.edu : sne ~-1,#0 : jmp -1,<-2 : mov bomb,@-3 : Where ~ represents looking into the queue for pointers. Any program that : had tons of processes would have to deal with queue scanners. Perhaps a : counter would be sending fake pointer to the queue. Well, how do we determine if a check in the process queue finds something? If I have one process, and you look at my process queue, do you have to scan through 8000 entries trying to find me? Or is my queue exactly what it is in pMars - 1 entry for example. Then, the process queue is worthless, as I can be found as quickly as Steven. Even if you have to scan, beaten Steven's qill be tough because you have to hit the sne, jmp, mov at the right time, or his sudden rabbit burst of 4096 dat movs will get you. Still doesn't sound good to me. : John - Randy From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Re: Revolutionary Redcode Changes Date: 1995/06/19 Message-ID: <1995Jun19.192034.2787@rhodes>#1/1 references: <1995Jun15.131414.2785@rhodes> <3rsbes$gru@newsbf02.news.aol.com> newsgroups: rec.games.corewar JLewisOS (jlewisos@aol.com) wrote: : <> "*" : Dwarf programs are already defeated by moving you program around the core, : I don't see why this would change. Dwarf specifically is, but there are some good stones that aren't beaten that easily just because you're moving (Keystone for example). : *"I imagine if this change were implemented, I could win a lot of : combats with this warrior: : mov.i 2, <1 : jmp.a -1, <-1 : I would be very hard to find, and in ~16000 cycles, I would have swept : core. Unless a warrior used pickets and moved itself, the battle : would be over before I wiped myself out."* : Most scanner would find you before that, your trail of altered DAT : statements would lead right to you. I have a feeling that what Dewey : thought about Mice the first year applies here. New strategies will : evolve to combat old ones. OK, how about mov.i 2, <1 jmp.a -1, #-1 I lay a stream of dat.f 0,0. No scanners find me, stones may or may not hit me. And as soon as I hit one body of a paper or the tail of an imp ring, I win. Too easy. Only way to beat this is something like S. Morrell suggested, using about a dozen lines to build up a good process of mov executions. Then the battle is over in 13.5 rounds instead of 8000 with mine (on average). : *"How could we tell then who gets credit for hitting a spot. Suppose I : drop an spl bomb on a stone at the same time it self-modifies and : moves its sweep line in place. Who gets that location? : "* : When I said "simultaneously" it was a bad choice of wording. What I mean : is that all the processes for one program are evaluated before evaluating : the next program's processes. If your program has eight processes it : would evaluate all eight before processing the opponents code. Gotcha. I see this now, and I'm even more opposed than I was originally. : *"Well, unfortunately warriors already have access to coresize. In the : original paper on CoreWar (by A.K. Dewdney), nothing was known about : core. With the latest pMars, CoreSize, # of Cycles, and a few other : things can be gotten. I'm not sure how much this has affected the : game, but I think it probably reduces the challenge at least a little : (especially knowing coresize)."* : I guess I mean it would be interesting to have access to changing some of : the parameters of the core. Perhaps it would be possible to change the : maximum number of processes, or change core size while running the : simulation. I haven't fully envisioned the amount of control a program : would have, but I am interested in input about what everyone finds : interesting. Allow my warrior to change core size? What if I change it to 8091, and then the enemy changes it to 7094? Or I change the process limit to 1, so I always beat S.Morrell SuperMegaClearEmOutWorm (is that the right name??). Munching on high level external stuff like that should not happen. It's bad enough pMars allows all that information to be accessed as it is. : John Lewis : JLewisOS@aol.com : Randy From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Re: Revolutionary Redcode Changes Date: 1995/06/19 Message-ID: <1995Jun19.191408.2786@rhodes>#1/1 references: <3rnism$b4u@newsbf02.news.aol.com> <1995Jun15.131414.2785@rhodes> newsgroups: rec.games.corewar Steven C. Morrell (morrell@jeeves.math.utah.edu) wrote: : In article <1995Jun15.131414.2785@rhodes> graham@harlie.mathcs.rhodes.edu (Randy Graham) writes: : JLewisOS (jlewisos@aol.com) wrote: : : What new strategies could be used, what old ones would become obsolete? : Stones would be even more popular. Silk paper and probably imp ring : would go away. : Stones? Obsolete against this warrior: : for 12 : spl 1 : rof : mov 2,<-1 : mov 1,<-2 : end : Any warrior who can't find and kill me in an average of 13.5 rounds is : toast! Imp rings wouldn't survive because you just have to kill the : trailing process. And 13.5 rounds hardly gives most programs a chance : to start up. So much for variety of warriors! I misunderstood the simul. part of the original suggestion. I thought it meant you and I both go at the same time. Now that I see he meant all my processes go once, then all your processes, I see why stones would be fairly useless. : (Just my $.02 worth.) : Steven Morrell morrell@math.utah.edu Randy From: sieben@imap1.asu.edu Subject: home pages Date: 1995/06/19 Message-ID: <3s2gld$deu@news.asu.edu>#1/1 newsgroups: rec.games.corewar I have some suggestions for the homepage owners. Some info on the ICWS tournaments would be nice. What I have in mind is a list of the say first 3 winners including source, picture of the author, description of the strategy used, etc. Access to the ICWS newsletters could clear up the mess created by the unusual format of the newsletters. A picture of Dewdney. It would be nice to have a hall of fame. We could look at pictures of the familiar names. A first position on a hill or a certain age of a warrior could automatically create a password for the author. The author then could use this password to upload a picture file. Nandor. From: KOTH Tourney Server Subject: SKI-ICWS: Status - Standard Date: 1995/06/19 Message-ID: <199506190400.AAA21178@valhalla.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status See up to the seconds scores at http://www.stormking.com/~koth Current Status of the StormKing Industries Standard KotH CoreWar Hill : # %W/ %L/ %T Name Author Score Age 1 34/ 16/ 50 Cannonade P.Kline 152 51 2 50/ 50/ 0 Unknown Wolfgang Weisser 151 12 3 41/ 36/ 23 Christopher Steven Morrell 147 16 4 32/ 17/ 51 ttti nandor sieben 147 1 5 33/ 21/ 46 Blue Funk 88 Steven Morrell 146 15 6 35/ 24/ 42 Test Wayne Sheppard 145 40 7 44/ 45/ 11 bigproba nandor sieben 143 39 8 31/ 19/ 49 Peace Mr. Jones 143 25 9 32/ 22/ 45 CAPS KEY IS STUCK AGAIN Steven Morrell 142 17 10 28/ 14/ 58 Imps! Imps! Imps! Steven Morrell 142 62 11 40/ 39/ 21 Beholder's Eye V1.7 W. Mintardjo 141 95 12 38/ 36/ 25 Keystone t21 P.Kline 140 38 13 42/ 44/ 14 Iron Gate Wayne Sheppard 140 145 14 42/ 45/ 13 Dagger v4.1 Michael Constant 138 60 15 31/ 27/ 42 Der Zweiter Blitzkrieg Mike Nonemacher 136 46 16 37/ 38/ 25 .T.E.S.T. V0.1 P.E.M & E.C 135 48 17 30/ 27/ 43 Hydra Stephen Linhart 134 125 18 37/ 42/ 21 Titled Steven Morrell 132 14 19 37/ 44/ 19 Summer Kitten Richard van der Brug 129 41 20 5/ 0/ 0 Smoke v1.3a Brian Zellner 14 13 21 2/ 98/ 0 Unknown Anonymous 7 0 From: KOTH Tourney Server Subject: SKI-ICWS: Status - Multiwarrior Experimental 94 Date: 1995/06/19 Message-ID: <199506190400.AAA25805@valhalla.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status See up to the seconds scores at http://www.stormking.com/~koth Current Status of the StormKing Industries MultiWarrior Experimental 94 CoreWar Hill: # Name Author Score Age 1 TimeScapeX (0.1) J. Pohjalainen 8661 12 2 Lucky 13 Stefan Strack 6687 14 3 life Nandor Sieben 6643 13 4 Shwing! T. H. Davies 6313 8 5 AB Scanner 2.9 Chris Hodson 5357 1 6 MuDwarf G. Eadon 3339 2 7 Veeble Jr. T. H. Davies 2642 9 8 Bloody! G. Eadon 2130 5 9 Agilulfo 1.1 Beppe Bezzi 1972 4 10 AB Scanner 2.8.1 Chris Hodson 0 10 11 Ochre Jelly v1.1 Brian Zellner 0 6 12 MuDwarf G. Eadon 0 3 13 Ochre Jelly v1.0 Brian Zellner 0 7 14 AB Scanner 2.8 Chris Hodson 0 11 15 None Nobody 0 15 16 None Nobody 0 15 17 None Nobody 0 15 18 None Nobody 0 15 19 None Nobody 0 15 20 None Nobody 0 15 21 None Nobody 0 15 From: pk6811s@acad.drake.edu Subject: Re: Revolutionary Redcode Changes Date: 1995/06/20 Message-ID: <1995Jun20.140622@acad.drake.edu>#1/1 references: <1995Jun19.192034.2787@rhodes> <3s6mag$sfl@newsbf02.news.aol.com> newsgroups: rec.games.corewar > :OK, how about > : mov.i 2, <1 > : jmp.a -1, #-1 > : > Sounds like a great strategy, why doesn't it win now? Under current rules this program bombs one location in two cycles making it a 50% (of c) bomber. A standard cmp-scanner runs at 66% giving it enough of a speed advantage to win more games. And this program is helpless against any kind of replicator, who can stand to lose a few copies while finding you out. Using S. Morrel's idea, a very good strategy would be to build up a large number of processes, then do something all at once. A few strategies would develop balancing number of processes, efficiency of attack, size and distribution of program, etc. But his bomber-template creates a very tough upper limit on the number of times through the process queue you would get - about 13. How much examination of the environment can be accomplished in that time? If he gets his turn to bomb you are dead, you can't run and you can't hide. Maybe you could make 100 copies of yourself in round 12. If in his turn he kills off the 50th copy, 49 copies will still have their turn before you die, which begs the question of fairness. If I have to finish round 13 successfully don't you? >... > Interweaving processes is actually rather odd when you think about it. >... Interweaving processes is an approximation of the real world where every organism moves about simultaneously. One doesn't get turned off while the next gets a whole day to run about. >... > If programs are to become more intelligent they need to > have the tools to find information, and they need to be able to affect Even in the real world the vast majority of organisms are not intelligent but depend on good design/adaptation to survive in their environment. Tell us what are you looking for when you say 'intelligent'. When people talk about 'intelligent' programs it leaves me blank. How many states can be put in a program of a few dozen lines? And how many does it take to be called 'intelligent'? Interesting discussion :-) Paul Kline pk6811s@acad.drake.edu From: jlewisos@aol.com (JLewisOS) Subject: Re: Revolutionary Redcode Changes Date: 1995/06/20 Message-ID: <3s6naf$snt@newsbf02.news.aol.com>#1/1 references: <1995Jun19.192407.2788@rhodes> newsgroups: rec.games.corewar :Well, how do we determine if a check in the process queue finds :something? If I have one process, and you look at my process queue, :do you have to scan through 8000 entries trying to find me? Or is my :queue exactly what it is in pMars - 1 entry for example. Then, the :process queue is worthless, as I can be found as quickly as Steven. :Even if you have to scan, beaten Steven's qill be tough because you :have to hit the sne, jmp, mov at the right time, or his sudden rabbit :burst of 4096 dat movs will get you. Still doesn't sound good to me. If the queue were for 8000 entries, the queue would be filled with a flag (the -1 you mention would be great). Each process would fill one slot and would have a positive number. If you found the correct process you could launch an attack. Programs the SPL to the maximum would be very vulnerable to this type of attack. I'm curous, are you in favor of any changes to the standard? Does any of this sound good to you? From: jlewisos@aol.com (JLewisOS) Subject: Re: Revolutionary Redcode Changes Date: 1995/06/20 Message-ID: <3s6mag$sfl@newsbf02.news.aol.com>#1/1 references: <1995Jun19.192034.2787@rhodes> newsgroups: rec.games.corewar :OK, how about : mov.i 2, <1 : jmp.a -1, #-1 : :I lay a stream of dat.f 0,0. No scanners find me, stones may or may :not hit me. And as soon as I hit one body of a paper or the tail of :an imp ring, I win. Too easy. Only way to beat this is something :like S. Morrell suggested, using about a dozen lines to build up a :good process of mov executions. Then the battle is over in 13.5 :rounds instead of 8000 with mine (on average). Sounds like a great strategy, why doesn't it win now? : <> : :Gotcha. I see this now, and I'm even more opposed than I was :originally. Interweaving processes is actually rather odd when you think about it. You are correct that in 13-14 turns you could have 8000 processes (although I think a max process of 128 would be better) but in those 13-14 turns each side could have executed thousands of statements. You said earlier that 13 turns was too short, but in this version 13 turns can be a long time. :Allow my warrior to change core size? What if I change it to 8091, :and then the enemy changes it to 7094? Or I change the process limit :to 1, so I always beat S.Morrell SuperMegaClearEmOutWorm (is that the :right name??). Munching on high level external stuff like that should :not happen. It's bad enough pMars allows all that information to be :accessed as it is. The idea of changing coresize has a lot of problems. I only mentioned it as an example of a higher Mars function. (I am not in favor of allowing changes to coresize unless someone can come up with a good way to implement it.) Why do you think pMars shouldn't allow for information gathering? If programs are to become more intelligent they need to have the tools to find information, and they need to be able to affect the enviroment. In the '88 standard there were very few ways to do either. CMP and MOV were two of the few ways to look at core and affect core. The '94 standard increased the power of funtions like ADD and JMP by allowing the B value to change core. This opened up several new strains of programs (ex:ROTLD tng) that use these tools to change core. I like the idea of new strategies, but strategies are limited to the tools at hand. There are simply not enough ways for a program to understand and change it's enviroment. John- From: KMPETERS@vax1.acs.jmu.edu (KENT M PETERSON) Subject: Re: Revolutionary Redcode Changes Date: 1995/06/21 Message-ID: <3s9c9o$5l2@doc.jmu.edu> references: <1995Jun19.192034.2787@rhodes> <3s6mag$sfl@newsbf02.news.aol.com> newsgroups: rec.games.corewar In <3s6mag$sfl@newsbf02.news.aol.com> jlewisos@aol.com writes: > :OK, how about > : mov.i 2, <1 > : jmp.a -1, #-1 > : > :I lay a stream of dat.f 0,0. No scanners find me, stones may or may > :not hit me. And as soon as I hit one body of a paper or the tail of > :an imp ring, I win. Too easy. Only way to beat this is something > :like S. Morrell suggested, using about a dozen lines to build up a > :good process of mov executions. Then the battle is over in 13.5 > :rounds instead of 8000 with mine (on average). > > Sounds like a great strategy, why doesn't it win now? Because there are other processes jumping around, over the attack. > : <> > : > :Gotcha. I see this now, and I'm even more opposed than I was > :originally. > > Interweaving processes is actually rather odd when you think about it. > You are correct that in 13-14 turns you could have 8000 processes > (although I think a max process of 128 would be better) but in those > 13-14 turns each side could have executed thousands of statements. > You said earlier that 13 turns was too short, but in this version > 13 turns can be a long time. This hinges on the way that SPL works currently, and the fact that, in spite of the simplicity of the warrior described above, no program "intelligent" enough to dodge it can survive in the current standard. More on this below. > :Allow my warrior to change core size? What if I change it to 8091, > :and then the enemy changes it to 7094? Or I change the process limit > :to 1, so I always beat S.Morrell SuperMegaClearEmOutWorm (is that the > :right name??). Munching on high level external stuff like that should > :not happen. It's bad enough pMars allows all that information to be > :accessed as it is. > > The idea of changing coresize has a lot of problems. I only mentioned it > as an example of a higher Mars function. (I am not in favor of allowing > changes to coresize unless someone can come up with a good way to > implement it.) This is actually simple enough, and has a lot of merit. Have coresize be changed by a certain (small) maximum per cycle - say, 5 cells. Growing core is not a problem (if it is, your warrior is badly designed for the new system). Only let unmodified core be "shrunk" (removed from play) - that is, core that has been changed from dat 0 0 cannot be cut out this way. This gives us a minimum coresize of the total length of the two contestants. Assuming they will be fooling around more or less continuously with the coresize, as core gets written to, the minimum size will gradually increase. You could have some very interesting battles here. > Why do you think pMars shouldn't allow for information > gathering? > > If programs are to become more intelligent they need to > have the tools to find information, and they need to be able to affect > the enviroment. In the '88 standard there were very few ways to do > either. CMP and MOV were two of the few ways to look at core and > affect core. The '94 standard increased the power of funtions like > ADD and JMP by allowing the B value to change core. This opened > up several new strains of programs (ex:ROTLD tng) that use these > tools to change core. I like the idea of new strategies, but strategies > are limited to the tools at hand. There are simply not enough ways for > a program to understand and change it's enviroment. Personally, I think both the 88 and 94 standards have a tremendous weakness in their method of implementing SPL. The only way to be successful is to have lots of processes running about, which pretty much automatically prevents the precision necessary to implement the more complex strategies that are occasionally suggested. For instance, given John Lewis's third proposal, I could imagine a warrior that modified the coresize to avoid a bomber, or to change its own bombing pattern. The problem with this kind of thing is that it must be done carefully, and that is best done with one process at a time, something that just isn't used anymore. Another unhappy side effect is that you can have so many processes that, even if they end up on a DAT, they don't all die before the battle is over. There ought to be benefits to avoiding this route. Also, it really looks like Redcode has run into something of a dead end. Oh yes, I know, "It took us years to explore 88, and we've barely started on 94," but most of those years of coding in 88 were done without KotH, which is the ultimate accelerator of Redcode evolution. The people currently on the hill (no, I'm not dedicated enough to be there) have learned a lot about "ideal" Redcode programming (optimal bombing etc.), and the pace of innovation should have been (IMHO) a lot faster than it is. The thing is, the 94 standard doesn't really make room for new strategies, it just makes it easier to efficiently implement the old ones, and to trash the core with 5 lines or less. I've been reading this group for a long time, and the last major innovation was imp-rings, back when everyone was still using 88. Since then, there have been improvements (Cannonade etc.) but these often consist of trying new constants or adding/modifying a few lines - never anything spectacular, like Synch, for instance. You've got the basic 3 strategies, and no room for anything else, because the major impact of 94 code is to make it easy to annihilate everything in <5 lines. This is why it is, IMHO, not an optimal improvement: the more lines any one program uses to do its thing, the easier it is to introduce more complex ideas that can compete with the Redcode written by C programs. The big problem with complexity is that it gets smashed flat by SPL 0, which, as I said above, is Redcode's biggest weakness and ought to be fixed. Maybe John Lewis's first 2 suggestions, or a modification of his third allowing the programs to control (somewhat) their own process limit, or the descendant- count modification that was talked about but never tried, or a lower process limit (though that seems somewhat artificial), or my own idea of instituting a "password" (defaults to 0, changed by SPW A B from A to B, B-field of SPL must be the correct password or SPL acts as NOP). Whatever happens, you shouldn't just say "that's a stupid idea, forget it" without even trying it. No progress will ever be made with that kind of attitude. In <3s6mag$sfl@newsbf02.news.aol.com> jlewisos@aol.com writes: > :OK, how about > : mov.i 2, <1 > : jmp.a -1, #-1 > : > :I lay a stream of dat.f 0,0. No scanners find me, stones may or may > :not hit me. And as soon as I hit one body of a paper or the tail of > :an imp ring, I win. Too easy. Only way to beat this is something > :like S. Morrell suggested, using about a dozen lines to build up a > :good process of mov executions. Then the battle is over in 13.5 > :rounds instead of 8000 with mine (on average). > > Sounds like a great strategy, why doesn't it win now? > > : <> > : > :Gotcha. I see this now, and I'm even more opposed than I was > :originally. > > Interweaving processes is actually rather odd when you think about it. > You are correct that in 13-14 turns you could have 8000 processes > (although I think a max process of 128 would be better) but in those > 13-14 turns each side could have executed thousands of statements. > You said earlier that 13 turns was too short, but in this version > 13 turns can be a long time. > > :Allow my warrior to change core size? What if I change it to 8091, > :and then the enemy changes it to 7094? Or I change the process limit > :to 1, so I always beat S.Morrell SuperMegaClearEmOutWorm (is that the > :right name??). Munching on high level external stuff like that should > :not happen. It's bad enough pMars allows all that information to be > :accessed as it is. > > The idea of changing coresize has a lot of problems. I only mentioned it > as an example of a higher Mars function. (I am not in favor of allowing > changes to coresize unless someone can come up with a good way to > implement it.) > > Why do you think pMars shouldn't allow for information > gathering? > > If programs are to become more intelligent they need to > have the tools to find information, and they need to be able to affect > the enviroment. In the '88 standard there were very few ways to do > either. CMP and MOV were two of the few ways to look at core and > affect core. The '94 standard increased the power of funtions like > ADD and JMP by allowing the B value to change core. This opened > up several new strains of programs (ex:ROTLD tng) that use these > tools to change core. I like the idea of new strategies, but strategies > are limited to the tools at hand. There are simply not enough ways for > a program to understand and change it's enviroment. > > John- From: graham@harlie.mathcs.rhodes.edu (Randy Graham) Subject: Re: Revolutionary Redcode Changes Date: 1995/06/21 Message-ID: <1995Jun21.174120.2789@rhodes>#1/1 references: <1995Jun19.192407.2788@rhodes> <3s6naf$snt@newsbf02.news.aol.com> newsgroups: rec.games.corewar JLewisOS (jlewisos@aol.com) wrote: [questioning process queue lookups deleted] : If the queue were for 8000 entries, the queue would be filled with a flag : (the -1 you mention would be great). Each process would fill one slot and : would have a positive number. If you found the correct process you could : launch an attack. Programs the SPL to the maximum would be very : vulnerable to this type of attack. Well, what I meant was - in pMars as it is, if I only have one process, I only have one process queue entry (I think that is how they wrote it). If the queue is only the size of the number of processes you have, I think I would be one dead pup rather quickly (in fact, in this case, the first warrior to go would always win). On the other hand, if the queue is the size of MAXPROCESSES, and a 0 meant no process there, and a 1 meant a process for which you could get a location, that would be more interesting. Still, getting the right timing on a process queue lookup and attack would be crucial in beating S.Morrell's super sweeper. : I'm curous, are you in favor of any changes to the standard? Does : any of this sound good to you? I would love to change the standard. I am still waiting for an ijn to balance the djn. I have a very interesting warrior that wastes too much time avoiding itself when run with djn, but which would be quite a bit more successful with ijn, I think. It's just your suggestions don't seem solid enough for me yet. Randy From: k12frsxs@vaxa.hofstra.edu (SUNDEEPAN SEN) Subject: A very good Redcode Date: 1995/06/21 Message-ID: <1995Jun21.171830.1@vaxa>#1/1 newsgroups: rec.games.corewar ; JUMP ; SOULHUNTER ; JMP INIT FROM DAT 0 SPL DOUBLEIMP INIT MOV #11, FROM LOOP MOV @FROM, #1/1 references: <1995Jun20.140622@acad.drake.edu> newsgroups: rec.games.corewar >Using S. Morrel's idea, a very good strategy would be to build up a >large number of processes, then do something all at once. A few strategies >would develop balancing number of processes, efficiency of attack, size >and distribution of program, etc. But his bomber-template creates a >very tough upper limit on the number of times through the process queue >you would get - about 13. How much examination of the environment >can be accomplished in that time? I would expect that you could go two routes, either build up as many processes as he is using for your queue scan, or simply scan "randomly" ten times. The Ten scans would give you a fairly good chance of finding someone who is trying to max out the queue. (I don't have time right now to figure out the percentage, but I will if you like.) >If he gets his turn to bomb you are dead, >you can't run and you can't hide. Maybe you could make 100 copies of yourself >in round 12. If in his turn he kills off the 50th copy, 49 copies will >still have their turn before you die, which begs the question of fairness. >If I have to finish round 13 successfully don't you? Interesting question. When does the programs die, right after the first illegal instruction or after the queue is finished and the "illegal instruction" flag has been flipped. I like the latter idea, if only because SOME ties would be nice. :) >Interweaving processes is an approximation of the real world where every >organism moves about simultaneously. One doesn't get turned off while >the next gets a whole day to run about. But in nature there are no ways to "SPL". While the child birth analogy does come seem like it fits this criteria, I think this only supports my side of the issue. (Communities often work simulaneously to create things.) Another idea for keeping ties to a minimum that I thought about was having a "Prime" process. The first process created was actually the program, and the SPL processes were only shadows. The goal of the game would be to destroy the "Prime" process, but this is probably a discussion for another thread. >Even in the real world the vast majority of organisms are not intelligent >but depend on good design/adaptation to survive in their environment. >Tell us what are you looking for when you say 'intelligent'. When people >talk about 'intelligent' programs it leaves me blank. How many states >can be put in a program of a few dozen lines? And how many does it take >to be called 'intelligent'? For me, an intelligent program use information gathered during the game in order to eliminate it's opponent. Programs that simply run a scripted series are "dumb". I have written my fair share of "dumb" programs, and I know that it does NOT reflect on the programmer's skill, but I find intelligent programs more interesting. I like to see programs react to the enemy. >Interesting discussion :-) > >Paul Kline >pk6811s@acad.drake.edu Isn't it, though. Do you find some of these ideas interesting enough to try? John- From: k12frsxs@vaxa.hofstra.edu (SUNDEEPAN SEN) Subject: Need help on making redcode warriors Date: 1995/06/22 Message-ID: <1995Jun22.131604.1@vaxa>#1/1 newsgroups: rec.games.corewar Hi I just started playing corewars on 06/21/95 and i dont have a clue on how to program redcode warriors see the simulator i have is a icws 88 complaint. I need a tutorial on how to make redcode warriors using ICWS 88. *** Sundeepan Sen *** HELLLPPPPPPP From: macaul@vvm.com (Robert) Subject: Corewars Date: 1995/06/22 Message-ID: <3sac25$7t4@ns.vvm.com>#1/1 newsgroups: rec.games.corewar Where can I get a copy of corewars? This sounds like a neat game and I would like to learn more about it. From: jlewisos@aol.com (JLewisOS) Subject: Re: Revolutionary Redcode Changes Date: 1995/06/22 Message-ID: <3sc2c7$b63@newsbf02.news.aol.com>#1/1 references: <1995Jun21.174120.2789@rhodes> newsgroups: rec.games.corewar :Well, what I meant was - in pMars as it is, if I only have one :process, I only have one process queue entry (I think that is how they :wrote it). If the queue is only the size of the number of processes :you have, I think I would be one dead pup rather quickly (in fact, in :this case, the first warrior to go would always win). On the other :hand, if the queue is the size of MAXPROCESSES, and a 0 meant no :process there, and a 1 meant a process for which you could get a :location, that would be more interesting. Still, getting the right :timing on a process queue lookup and attack would be crucial in :beating S.Morrell's super sweeper. As I remember it, the "super sweeper" only had three lines. If my queue scanner uses a carpet bombing routine then I can cover several locations in core at once. (centered on the process.) This would make the timing less important. :I would love to change the standard. I am still waiting for an ijn to :balance the djn. I have a very interesting warrior that wastes too :much time avoiding itself when run with djn, but which would be quite :a bit more successful with ijn, I think. It's just your suggestions :don't seem solid enough for me yet. : :Randy I agree, my suggestions are not built in stone (NPI). I wanted to expose these ideas to the public forum to that time would not be lost on parts of the idea that simply wont work. I appreciate your input and I understand your concerns. We both want to make Corewar fun, lets concentrate on that. The major problem I see with the current standard is the limit number of strategies that can be employed. Paper : SPL Stone : MOV Scissors : CMP One might also include something about DJN for programs that just decrease core, but these tend to be added on later. My point here is that each of these program styles rely primarily on these instuctions. In order for new strategies to emerge I fear we may have to create more instructions. One way to keep the total number of instructions down is to replace some of the instructions that are hardly ever used. (Survival of the fittest instructions) How many KOTH programs use MUL or DIV or MOL? I agree with those people who say that we need to keep the number of instructions at a reasonalbe level. The question is how many should that be? QUE A,B Copy the queue location A to core B (relative to loction) END End a process without killing the program These two instuctions would allow for scanning the queue and for single process objective. The queue itself would be twice as large as MAXPROCESS, Negative location numbers would be your own processes and postive numbers would be the enemy. An example Starting queue would look like this: Queue Location Process Pointer ***** ***** ***** ***** +0003 -0001 +0002 -0001 +0001 +3723 ------------- -0001 +4763 -0002 -0001 -0003 -0001 ***** ***** ***** ***** Obviously the queue would work that same as the core, where a random starting location is used and relative number access the queue. John- From: jlewisos@aol.com (JLewisOS) Subject: Re: Revolutionary Redcode Changes Date: 1995/06/23 Message-ID: <3sfv4s$c34@newsbf02.news.aol.com>#1/1 references: <3se293$hac@news.manawatu.gen.nz> newsgroups: rec.games.corewar : How about taking this futher and introducing concepts like random :mutation and evelutionary code? Because of random mutations, programs :are forced to copy themselves, and split processes in order survice. :Mutations also allow them to evolve. : : Im not sure if this can be done with the corewar model, and it would :be hard to define a 'winner' and a 'loser' if your original programs :dont even exist in their original form. Count the processes? : : It would be interesting haveing a evelutionary hill at least. It :would almost be like a breeding tank. An evolutionary game would be great, but I am more interested in the corewar simulation. Is there anyone else out there that is interested in making more "intelligent" code? I would like more input on how to do this. From: jlewisos@aol.com (JLewisOS) Subject: Re: CORESIZE et al. (was Re: Revolutionary Redcode Changes) Date: 1995/06/23 Message-ID: <3sfuc2$bpg@newsbf02.news.aol.com>#1/1 references: <3sf1aq$d8j@news.vanderbilt.edu> newsgroups: rec.games.corewar I don't mind the predefined variable, but I also never use them. In general I create a warrior in the enviroment that I intend to submit it. If the Hill is 8000 then I make the warrior in an 8000 size core. I suggest keeping the predefined variable, as the use of them is voluntary. John - From: graham@joshua.mathcs.rhodes.edu (Randy Graham) Subject: Re: CORESIZE et al. (was Re: Revolutionary Redcode Changes) Date: 1995/06/23 Message-ID: <1995Jun23.163237.2790@rhodes>#1/1 references: <1995Jun15.131414.2785@rhodes> newsgroups: rec.games.corewar Stefan Strack (stst@vuse.vanderbilt.edu) wrote: [My gripe about known variables deleted] : CORESIZE, MAXPROCESSES, etc. are known to the programmer submitting : to KotH anyway, so I don't see how they could "reduce the challenge". : A different matter of course would be "random" tournaments with unknown : core parameters. I have always thought this would be an improvement. You would be forced to code for some kind of "intelligence" (sorry Paul) in your warrior to avoid self-destruction and reduce ties. Some bounds should be given, perhaps, to give a reasonable chance of warriors winning or losing instead of tying everything. A tourney coresize 7800-8200, max procs of 7000-12000, etc instead of current set definitions. I am sure this would be a pain to do for a hill, but it would probably increase variety (my guess). Unfortunately, this eliminates imps and probably some neat tricks (like iron ???? 3/9-point imp catching spl core clear), so it does have drawbacks too. In fact, the first decent warrior I ever submitted was a b-scanner that would work in all core sizes (although it might run too long or not long enough if the size varied significantly from 8000), didn't destroy itself, eventually terminated safely (unless, of course, it had been hit by another warrior), and did a core clear. However, it got trashed by a lot of good warriors who assumed certain things and therefore didn't need to waste code protecting them from themselves. : We added CORESIZE et al. to the pMARS Redcode syntax to aid in code : maintenance and to make writing "portable" warriors easier. You could : e.g. make your step size selection dependent on CORESIZE so your : warrior works on both 94 and 94x hills. Yes, I realize all this, and I'll admit I use these sometimes to make one source work for two hills. However, I always use ;assert 1 because I figure if I can't deal with the world as it is written, that's my problem for not writing them robustly enough (probably a better word than intelligent for a warrior). : Are there other people who don't like these predefined variables? Probably not. I'm guessing I'm the only one. And it isn't even that I don't like them. I just feel some of the challenge is lost when dealing with a static core. Just like I like the idea of filling core with "noise," I like the idea of changing core size. I know there are problems (scanners become FAR more difficult with a noisy core, imps become a challenge for cores that change size). : -Stefan Randy From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: CORESIZE et al. (was Re: Revolutionary Redcode Changes) Date: 1995/06/23 Message-ID: <3sf1aq$d8j@news.vanderbilt.edu>#1/1 references: <1995Jun15.131414.2785@rhodes> <3rsbes$gru@newsbf02.news.aol.com> <1995Jun19.192034.2787@rhodes> newsgroups: rec.games.corewar In article <1995Jun19.192034.2787@rhodes> graham@hal.mathcs.rhodes.edu (Randy Graham) writes: >: *"Well, unfortunately warriors already have access to coresize. In the >: original paper on CoreWar (by A.K. Dewdney), nothing was known about >: core. With the latest pMars, CoreSize, # of Cycles, and a few other >: things can be gotten. I'm not sure how much this has affected the >: game, but I think it probably reduces the challenge at least a little >: (especially knowing coresize)."* > [...] >It's bad enough pMars allows all that information to be >accessed as it is. > >Randy CORESIZE, MAXPROCESSES, etc. are known to the programmer submitting to KotH anyway, so I don't see how they could "reduce the challenge". A different matter of course would be "random" tournaments with unknown core parameters. We added CORESIZE et al. to the pMARS Redcode syntax to aid in code maintenance and to make writing "portable" warriors easier. You could e.g. make your step size selection dependent on CORESIZE so your warrior works on both 94 and 94x hills. Are there other people who don't like these predefined variables? -Stefan From: wolf@manawatu.planet.co.nz (Wilfred Verkley) Subject: Re: Revolutionary Redcode Changes Date: 1995/06/23 Message-ID: <3se293$hac@news.manawatu.gen.nz>#1/1 references: <1995Jun20.140622@acad.drake.edu> <3s9d4b$keg@newsbf02.news.aol.com> newsgroups: rec.games.corewar >>Interweaving processes is an approximation of the real world where every >>organism moves about simultaneously. One doesn't get turned off while >>the next gets a whole day to run about. ..... >>Even in the real world the vast majority of organisms are not intelligent >>but depend on good design/adaptation to survive in their environment. >>Tell us what are you looking for when you say 'intelligent'. When people >>talk about 'intelligent' programs it leaves me blank. How many states >>can be put in a program of a few dozen lines? And how many does it take >>to be called 'intelligent'? How about taking this futher and introducing concepts like random mutation and evelutionary code? Because of random mutations, programs are forced to copy themselves, and split processes in order survice. Mutations also allow them to evolve. Im not sure if this can be done with the corewar model, and it would be hard to define a 'winner' and a 'loser' if your original programs dont even exist in their original form. Count the processes? It would be interesting haveing a evelutionary hill at least. It would almost be like a breeding tank. "And the angels are decending, like a precious sending." \/\/ Wilfred Verkley \/\/ Word before too long, \/ wolf@manawatu.planet.co.nz \/ sing a lone star song." - GRANT LEE BUFFALO From: widfara@aol.com (Widfara) Subject: Newbie: How do I get started? Date: 1995/06/24 Message-ID: <3si9os$spj@newsbf02.news.aol.com>#1/1 newsgroups: rec.games.corewar Heard a desc of corewar...sounded cool, so I signed on this list. Can someone send me the FAQ or other info to get into Corewar? Much appreciated, Widfara@aol.com From: rossd@arbroath.win-uk.net (Derek Ross) Subject: Re: Revolutionary Redcode Changes Date: 1995/06/24 Message-ID: <143@arbroath.win-uk.net>#1/1 references: <1995Jun20.140622@acad.drake.edu><3s9d4b$keg@newsbf02.news.aol.com> newsgroups: rec.games.corewar In article <3s9d4b$keg@newsbf02.news.aol.com>, JLewisOS (jlewisos@aol.com) writes: >For me, an intelligent program uses information gathered during >the game in order to eliminate its opponent. Programs that simply >run a scripted series are "dumb". I have written my fair share of >"dumb" programs, and I know that it does NOT reflect on the >programmer's skill, but I find intelligent programs more >interesting. I like to see programs react to the enemy. John I think that this paragraph sums up your hopes for programs written to run on a changed MARS machine. I like what you say. However I don't think that changes in REDCODE specification will necessarily achieve what you want. It seems to me that any program's behaviour is caused by its objective. Since for core warriors this is basically 'remove all other processes', we end up with the type of programs we have. The only intelligence/knowledge involved is in finding the opponent and not removing too many of our own processes. Programmers will reduce as much of this intelligence/knowledge to 'dumb' program behaviour during 'compiletime' as they can, because 'dumb' behaviour runs faster than 'intelligent' behaviour. Even if you change the REDCODE ground rules in the way you suggest I think that this will remain true. On the other hand, to get the type of programs you are looking for, the redcode program objective could be changed without radical changes to MARS. Two possibilities strike me. 1) Combat takes place between two programs as at present but a third neutral program is also placed in core by the MARS loader before combat at some random position. If a combatant 'kills' the neutral program that combatant loses immediately. Otherwise results are decided as at present. 2) Each contestant must submit two warrior programs. These are placed at independent unknown positions in core by the MARS loader. Thus there are four warriors in core during any battle. The first contestant to lose one of its warriors loses the battle. Other suggestions could be made but the important point with both of these is that your warrior can't just go in gung-ho and blast everything in sight. It has to check and make sure it's hitting the right thing. That's the sort of thing that makes runtime intelligence necessary. Scanners do it in a limited way just now but they only have to differentiate between empty core and program which doesn't necessarily require a lot of sophistication. Anyway however you feel about these ideas, thanks for generating an interesting discussion and making me think a bit. Cheers Derek From: jlewisos@aol.com (JLewisOS) Subject: Re: Revolutionary Redcode Date: 1995/06/24 Message-ID: <3shhfj$m4f@newsbf02.news.aol.com>#1/1 references: <95062401215027165@infoway.com> newsgroups: rec.games.corewar : An evolutionary game has been done, to a certain extent. I recall reading a :paper about it from csua.berkeley.edu. fto there and check it out--it's :called evolving warriors. Kind of interesting, it'd be great if some :people could carry it on. I read it, it was very interesting. Anyone who found this interesting should read the work of Karl Sims. Amazing stuff. His two articles Evoling Virtual Creatures and Evolving 3D Morphology and Behavior by Competition are *very* informative. I don't remember the FTP site verbatum but it was something like "ftp.think.com". :It's frank.y very hard to make intelligent code with what's provided :in redcode. Mainly that code is limited to 100 lines. Not much room there. :(I know it's not really limited to 100 lines, that's just the standard :limit.) :-erik Do you really think the problem lies with the limited lines? I've done some "intelligent" programs with only 20-30 lines. It's just that they don't stand a chance against quick and dumb programs. If speed is what makes a program deadly then make intelligence faster. John - From: jlewisos@aol.com (JLewisOS) Subject: Re: Revolutionary Redcode Changes Date: 1995/06/24 Message-ID: <3sh92t$jvb@newsbf02.news.aol.com>#1/1 references: <143@arbroath.win-uk.net> newsgroups: rec.games.corewar :I like what you say. However I don't think that changes in REDCODE :specification will necessarily achieve what you want. Actually you make my point quite well. I will illuminate after quoting you a bit more... :It seems to me that any program's behaviour is caused by its :objective. Since for core warriors this is basically 'remove all :other processes', we end up with the type of programs we have. The :only intelligence/knowledge involved is in finding the opponent :and not removing too many of our own processes. Programmers :will reduce as much of this intelligence/knowledge to 'dumb' program :behaviour during 'compiletime' as they can, because 'dumb' behaviour :runs faster than 'intelligent' behaviour. Even if you change the :REDCODE ground rules in the way you suggest I think that this will :remain true. I agree with part of this, your point about "dumb" programs being faster than "intelligent" programs is quite right. It is just as fast to destroy parts of the core as scan them. (The exception to this is the program that uses the CMP instruction to compare two different parts of core to each other.) Perhaps the fault DOES lie in the redcode itself. Consider what would happen if instructions that gather information ran three times as fast as other statements. You could scan three core locations for in the same time you could move a DAT bomb. I think what this points to is a need for more powerful info- gathering tools. Here is an interesting idea for a more powerful scanner; The Process Scanner PSC A, B ;scan from A to B and skip next instruction is a process ;is present. :On the other hand, to get the type of programs you are looking for, :the redcode program objective could be changed without radical :changes to MARS. Two possibilities strike me. : :1) Combat takes place between two programs as at present but a third :neutral program is also placed in core by the MARS loader before :combat at some random position. If a combatant 'kills' the neutral :program that combatant loses immediately. Otherwise results are :decided as at present. : :2) Each contestant must submit two warrior programs. These are :placed at independent unknown positions in core by the MARS loader. :Thus there are four warriors in core during any battle. The first :contestant to lose one of its warriors loses the battle. Both these ideas have merit, but the first one a the major problem: which program to use as the neutral program. The second idea would make Paper very powerful. Most Paper can live with itself for quite a while. :Other suggestions could be made but the important point with both :of these is that your warrior can't just go in gung-ho and blast :everything in sight. It has to check and make sure it's hitting the :right thing. That's the sort of thing that makes :runtime intelligence necessary. Scanners do it in a limited way :just now but they only have to differentiate between empty core and :program which doesn't necessarily require a lot of sophistication. : :Anyway however you feel about these ideas, thanks for generating an :interesting discussion and making me think a bit. Thank you Derek, my real goal was to foster a dialog that would make CoreWars the type of game we all want it to be, challenging, fun, and creative. John- From: erik.hetzner@infoway.com (Erik Hetzner) Subject: Re: Revolutionary Redcode Date: 1995/06/24 Message-ID: <95062401215027165@infoway.com>#1/1 newsgroups: rec.games.corewar Jlewisos@aol.Com, In a message on 23 June, you wrote to me : JL> : It would be interesting haveing a evelutionary hill at least. It JL> :would almost be like a breeding tank. JL> JL> An evolutionary game would be great, but I am more interested in JL> the corewar simulation. An evolutionary game has been done, to a certain extent. I recall reading a paper about it from csua.berkeley.edu. fto there and check it out--it's called evolving warriors. Kind of interesting, it'd be great if some people could carry it on. JL> Is there anyone else out there that is interested in making more JL> "intelligent" code? I would like more input on how to do this. It's frank.y very hard to make intelligent code with what's provided in redcode. Mainly that code is limited to 100 lines. Not much room there. (I know it's not really limited to 100 lines, that's just the standard limit.) -erik --- � ATP/Linux 1.42 � I want to rise with the masses, not from them. From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 1995/06/25 Message-ID: newsgroups: rec.games.corewar,rec.answers,news.answers Archive-name: games/corewar-faq Last-Modified: 95/06/10 Version: 3.3 These are the Frequently Asked Questions (and answers) from the Usenet newsgroup rec.games.corewar. A plain text version of this document is posted every two weeks. The hypertext version is available as _________________________________________________________________ Table of Contents 1. What is Core War 2. Is it Core War or Core Wars? 3. Where can I find more information about Core War? 4. Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? 5. What is ICWS'94? Which simulators support ICWS'94? 6. What is the ICWS? 7. What is TCWN? 8. How do I join? 9. What is the EBS? 10. Where are the Core War archives? 11. Where can I find a Core War system for ...? 12. I do not have FTP. How do I get all this great stuff? 13. I do not have access to Usenet. How do I post and receive news? 14. Are there any Core War related WWW sites? 15. When is the next tournament? 16. What is KotH? How do I enter? 17. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 18. How does SLT (Skip if Less Than) work? 19. What is the difference between in-register and in-memory evaluation? 20. What does (expression or term of your choice) mean? 21. Other questions? _________________________________________________________________ What is Core War? 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 processes of the opposing program 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. [ToC] _________________________________________________________________ Is it "Core War" or "Core Wars"? 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. [ToC] _________________________________________________________________ Where can I find more information about Core War? 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. [ToC] _________________________________________________________________ Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? A draft of the official standard (ICWS'88) is available as . This document is formatted awkwardly and contains ambiguous statements. For a more approachable intro to Redcode, take a look at Mark Durham's tutorial, and . 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@csua.berkeley.edu) is reportedly working on a beginner's introduction. [ToC] _________________________________________________________________ What is ICWS'94? Which simulators support ICWS'94? 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. You can try out the new standard by submitting warriors to the '94 hills of the KotH servers. Two corewar systems currently support ICWS'94, pMARS (many platforms) and Redcoder (Mac), both available at ftp.csua.berkeley.edu. [ToC] _________________________________________________________________ What is the ICWS? 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). [ToC] _________________________________________________________________ What is TCWN? 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 files. [ToC] _________________________________________________________________ How do I join? 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. [ToC] _________________________________________________________________ What is the EBS? 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. [ToC] _________________________________________________________________ Where are the Core War archives? 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 (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@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. The plain text version of this FAQ is automatically archived by news.answers. [ToC] _________________________________________________________________ Where can I find a Core War system for . . . ? 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 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 ftp.csua.berkeley.edu: 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 (without extensions) 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) pmars07s.zip - portable system, ICWS'88 and '94, runs on UNIX, PC, Mac, Amiga. C source archive pmars07s.tar.Z - same as above pmars07.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) [ToC] _________________________________________________________________ I do not have FTP. How do I get all this great stuff? 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. [ToC] _________________________________________________________________ I do not have access to Usenet. How do I post and receive news? To receive rec.games.corewar articles by email, join the COREWAR-L list run on the Stormking.Com list processor. To join, send the message 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. [ToC] _________________________________________________________________ Are there any Core War related WWW sites? You bet. Each of the two KotH sites sport a world-wide web server. Stormking's Core War page is ; pizza's is . A third WWW site is in Koeln, Germany: . Last but not least, Stephen Beitzel's "Unofficial Core War Page" is . All site are in varying stages of construction, so it would be futile to list here what they have to offer. [ToC] _________________________________________________________________ When is the next tournament? 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 and other types of tournaments are held frequently among readers of the newsgroup; watch there for announcements or contact me. [ToC] _________________________________________________________________ What is KotH? How do I enter? 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 (warrior) with special comment lines. You will receive a reply indicating how well your program did against the current top programs "on the hill". There are two styles of KotH tournaments, "classical" and "multi-warrior". The "classical" KotH is a one-on-one tournament, that is your warrior 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. In "multi-warrior" KotH, all warriors on the hill fight each other at the same time. Score calculation is a bit more complex than for the one-on-one tournament. Briefly, points are awarded based on how many warriors survive until the end of a round. A warrior that survives by itself gets more points than a warrior that survives together with other warriors. Points are calculated from the formula (W*W-1)/S, where W is the total number of warriors and S the number of surviving warriors. The pMARS documentation has more information on multi-warrior scoring. The idea for an email-based Core War server came from David Lee. The original KotH was developed and run by William Shubert at Intel starting in 1991, 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). Up until May '95, the two sites provided overlapping services, i.e. the some of the hill types were offered by both "pizza" and "stormking". To conserve resources, the different hill types are now divided up among the sites. The way you submit warriors to both KotHs is pretty much the same. Therefore, the entry rules described below apply to both "pizza" and "stormking" unless otherwise noted. 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" (or ";redcode-94, etc., see below) 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 seven separate hills you can select by starting your program with ;redcode-b, ;redcode-94, ;redcode-94x, ;redcode, ;redcode-icws, ;redcode-94m or ;redcode-94xm. The former three run at "pizza", the latter four at "stormking". 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 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 you should get more mail telling you how your program performed against the current top 20 (or 10) 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") hillsize: 20 warriors rounds: 100 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") hillsize: 20 warriors rounds: 100 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'94 Draft Hill Specs: (Accessed with ";redcode-94", available at "pizza") hillsize: 20 warriors rounds: 100 coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: extended ICWS '94 Draft ICWS'94 Beginner's Hill Specs: (Accessed with ";redcode-b", available at "pizza") hillsize: 20 warriors rounds: 100 coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: extended ICWS '94 Draft max. age: after 100 successful challenges, warriors are retired. ICWS'94 Experimental (Big) Hill Specs: (Accessed with ";redcode-94x", available at "pizza") hillsize: 20 warriors rounds: 100 coresize: 55440 max. processes: 10000 duration: after 500,000 cycles, a tie is declared. max. entry length: 200 minimum distance: 200 instruction set: extended ICWS '94 Draft ICWS'94 Draft Multi-Warrior Hill Specs: (Accessed with ";redcode-94m", available at "stormking") hillsize: 10 warriors rounds: 200 coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: extended ICWS '94 Draft ICWS'94 Experimental (Big) Multi-Warrior Hill Specs: (Accessed with ";redcode-94xm", available at "stormking") hillsize: 20 warriors rounds: 100 coresize: 55440 max. processes: 10000 duration: after 500,000 cycles, a tie is declared. max. entry length: 200 minimum distance: 200 instruction set: extended 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. At stormking, a message body with ";help" will return brief instructions. If you submit code containing a ";test" line, your warrior will be assembled but not actually pitted against the warriors on the hill. All hills run portable MARS (pMARS) version 0.7, a platform-independent corewar system available at ftp.csua.berkeley.edu. 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 [ToC] _________________________________________________________________ Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 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. [ToC] _________________________________________________________________ How does SLT (Skip if Less Than) work? 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. [ToC] _________________________________________________________________ What is the difference between in-register and in-memory evaluation? These terms refer to the way instruction operands are evaluated. The '88 Redcode standard ICWS'88 is unclear about whether a simulator should "buffer" the result of A-operand evaluation before the B-operand is evaluated. Simulators that do buffer are said to use in-register evaluation, those that don't, in-memory evaluation. ICWS'94 clears this confusion by mandating in-register evaluation. Instructions that execute differently under these two forms of evaluation are MOV, ADD, SUB, MUL, DIV and MOD where the effective address of the A-operand is modified by evaluation of the B-operand. This is best illustrated by an example: L1 mov b, mov.i #0,impsize 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, mov.i #0,impsize Mirror see reflection. On-axis/off-axis On-axis scanners compare two locations M/2 apart, where M is the memory size. Off-axis scanners use some other separation. Optimal Constants (also optima-type constants) Bomb or scan increments chosen to cover core most effectively, i.e. leaving gaps of uniform size. Programs to calculate optimal constants and lists of optimal numbers are available at ftp.csua.berkeley.edu. Paper A Paper-like program. One which replicates itself many times. Part of the Scissors (beats) Paper (beats) Stone (beats Scissors) analogy. Pit-Trapper (also Slaver, Vampire). A program which enslaves another. Usually accomplished by bombing with JMPs to a SPL 0 pit with an optional core-clear routine. Quick Scan 2c scan of a set group of core locations with bombing if anything is found. Both of the following codes snips scan 16 locations and check for a find. If anything is found, it is attacked, otherwise 16 more locations are scanned. Example: start s1 for 8 ;'88 scan cmp start+100*s1, start+100*s1+4000 ;check two locations mov #start+100*s1-found, found ;they differ so set pointer rof jmn attack, found ;if we have something, get it s2 for 8 cmp start+100*(s2+6), start+100*(s2+6)+4000 mov #start+100*(s2+6)-found, found rof found jmz moveme, #0 ;skip attack if qscan found nothing attack cmp @found, start-1 ;does found points to empty space? add #4000, found ;no, so point to correct location mov start-1, @found ;move a bomb moveme jmp 0, 0 In ICWS'94, the quick scan code is more compact because of the SNE opcode: start ;'94 scan s1 for 4 sne start+400*s1, start+400*s1+100 ;check two locations seq start+400*s1+200, start+400*s1+300 ;check two locations mov #start+400*s1-found, found ;they differ so set pointer rof jmn which, found ;if we have something, get it s2 for 4 sne start+400*(s2+4), start+400*(s2+4)+100 seq start+400*(s2+4)+200, start+400*(s2+4)+300 mov #start+400*(s2+4)-found-100, found rof found jmz moveme, #0 ;skip attack if qscan found nothing add #100, -1 ;increment pointer till we get the which jmn -1, @found ;right place mov start-1, @found ;move a bomb moveme jmp 0, 0 Reflection Copy of a program or program part, positioned to make the active program invisible to a CMP-scanner. Replicator Generic for Paper. A program which makes many copies of itself, each copy also making copies. Self-Splitting Strategy of amplifying the number of processes executing a piece of code. example SPL 0 loop ADD #10, example MOV example, @example JMP loop Scanner A program which searches through core for an opponent rather than bombing blindly. Scissors A program designed to beat replicators, usually a (B-field scanning) vampire. Part of the Paper-Scissors-Stone analogy. Self-Repair Ability of a program to fix it's own code after attack. Silk A replicator which splits off a process to each new copy before actually copying the code. This allows it to replicate extremely quickly. This technique is only possible under the '94 draft, because it requires post-increment indirect addressing. Example: spl 1 mov.i -1, 0 spl 1 ;generate 6 consecutive processes silk spl 3620, #0 ;split to new copy mov.i >-1, }-1 ;copy self to new location mov.i bomb, >2000 ;linear bombing mov.i bomb, }2042 ;A-indirect bombing for anti-vamp jmp silk, {silk ;reset source pointer, make new copy bomb dat.f >2667, >5334 ;anti-imp bomb Slaver see Pit-Trapper. Stealth Property of programs, or program parts, which are invisible to scanners, accomplished by using zero B-fields and reflections. Stone A Stone-like program designed to be a small bomber. Part of the Paper-Scissors-Stone analogy. Stun A type of bomb which makes the opponent multiply useless processes, thus slowing it down. Example is referred to as a spl-jmp bomb. example spl 0 jmp -1 Two-Pass Core-Clear (also spl/dat Core-Clear) core clear that fills core first with SPL instructions, then with DATs. This is very effective in killing paper and certain imp-spiral variations. Vampire see Pit-Trapper. Vector Launch one of several means to start an imp-spiral running. As fast as Binary Launch, but requiring much less code. See also JMP/ADD Launch and Binary Launch. This example is one form of a Vector Launch: impsize equ 2667 example spl 1 ; extend by adding more spl 1's spl 1 djn.a @imp,#0 ; jmp @ a series of pointers dat #0,imp+(3*impsize) dat #0,imp+(2*impsize) dat #0,imp+(1*impsize) dat #0,imp+(0*impsize) imp mov.i #0,impsize [ToC] _________________________________________________________________ Other questions? Just ask in the rec.games.corewar newsgroup or contact me (address below). If you are shy, check out the Core War archives first to see if your question has been answered before. [ToC] _________________________________________________________________ Credits Additions, corrections, etc. to this document are solicited. Thanks in particular to the following people who have contributed major portions of this document: Paul Kline, Randy Graham. Mark Durham wrote the first version of the FAQ. The rec.games.corewar FAQ is Copyright 1995 and maintained by: Stefan Strack, PhD stst@vuse.vanderbilt.edu Dept. Molecular Physiol. and Biophysics stst@idnsun.gpct.vanderbilt.edu Rm. 762, MRB-1 stracks@vuctrvax.bitnet Vanderbilt Univ. Medical Center Voice: +615-322-4389 Nashville, TN 37232-6600, USA FAX: +615-322-7236 _________________________________________________________________ $Id: corewar-faq.html,v 3.3 1995/06/10 16:18:05 stst Exp stst $ From: "A HORSE IS A HORSE(UNLESS IT'S A DOG)" Subject: What is the name of the multi warrior? Date: 1995/06/26 Message-ID: <01HS5XP64JEA00Q6B0@OCVAXA.CC.OBERLIN.EDU>#1/1 newsgroups: rec.games.corewar what should I use in the ;redcode portion of my code to enter the multiwarrior tourney? Thanks. -Paul P.S. Any people who, like me, have sucky code and want to discuss it, send me a note! Maybe we can exchange ideas... From: Adam Christie Subject: REQ: Ideas and suggestions for a new game idea. Date: 1995/06/26 Message-ID: <804181575snz@arquebus.demon.co.uk>#1/1 newsgroups: rec.games.corewar Hullo everyone, I hope this is slightly on subject... Recently I was watching "The Net" on BBC2 (UK) and at the end was a short article on a project called "TechnoSphere". It described how someone has made a huge fractal world, and is inviting WWW users to create creatures to inhabit this world and wander round it. The creatures will send back reports on how they are doing, what they have done, where they are, and a picture (2D) of what they can see by email to the creator. After watching it I started thinking how it could be made much more interesting. Basically, with a bit of violence and warfare in it. (Call me old-fashioned). So, I was wondering if any of you Core runners had any ideas for such a game (and I am thinking of something like BattleTech or whatever). Don't panic about disclaimers to ideas and so on, if they are used then they will be given FULL credit in the source, distribution and release versions. Besides which its going to be free anyway. (Don't get me wrong, I would like to sell such a game, its not as if I don't need the money, but after getting Linux recently, I realise the future is in free software... :> ie, no-one pays me for what I give them, I don't pay them for what I get.) Anyway, I would be interested in your ideas on this matter. (note, this will be posted in a similar form in rec.games.programmers, and some others when I can be bothered looking the relevant groups up). Thanks in advance, adamc. adamc@arquebus.demon.co.uk LINUX for KING From: jlewisos@aol.com (JLewisOS) Subject: Re: More Revolutionary Redcode Changes Date: 1995/06/26 Message-ID: <3sn9s8$5gs@newsbf02.news.aol.com>#1/1 references: <1995Jun26.120815@acad.drake.edu> newsgroups: rec.games.corewar :There's no way to make information gathering faster than bombing or all-out :replicating. The bombers will just use the scan process to their :advantage - glorified cmp-scanners. What is needed is something similar to :the Prisoner's Dilemma games (see Scientific American's last two issues). Yes you can make information gathering faster than bombing and all-out replicating. I have already given an example: PRC A,B Where the next instruction is skipped is there is a process between the A and B (using the shortest distance between the two) Your second point is lost on me, if it's a CMP-scanner then it's not a bomber, right? Bombers are dumb, scanners are intelligent. :This could be accomplished by adding one privileged word telling you :whether you won the last round or not, and a small number of memory :locations that retain their values from one battle to the next (and which :only you can update). I like the idea of a memory between matches, but I think you would just as easily change strategies at start up randomly. (In fact I think I will work on this tonight.) You make a great point about RND. We do need a random number generator. :Two highly adaptive programs might settle on alternating between bombing :and scanning, with an occasional go at replicating. Until someone comes :up with a better replicator that requires rewriting the bomb/scan component. Unfortunatly you only give the option of switching between states on a win or lose basis. What might be better is giving the program access to the win/lose/tie information between matches in the same way you let them use CORESIZE. John- From: pk6811s@acad.drake.edu Subject: More Revolutionary Redcode Changes Date: 1995/06/26 Message-ID: <1995Jun26.120815@acad.drake.edu>#1/1 newsgroups: rec.games.corewar There's no way to make information gathering faster than bombing or all-out replicating. The bombers will just use the scan process to their advantage - glorified cmp-scanners. What is needed is something similar to the Prisoner's Dilemma games (see Scientific American's last two issues). This could be accomplished by adding one privileged word telling you whether you won the last round or not, and a small number of memory locations that retain their values from one battle to the next (and which only you can update). This way you know everything you need to know about your opponent, which is whether you beat him using a particular strategy. You can change strategies during the 100 rounds (and so can he), optimize step sizes on the fly, etc. Or use RND to totally confuse the other. Any single-strategy program, like Silk, would quickly be identified as such and your program would settle on spl-carpet cmp-scanning as optimum. Any single-strategy program would be defeated easily by an adapter, which would have bomber, scanner, replicator, imp, with variations of each pre-programmed and pre-optimized, just needing to be turned on and tried. Two highly adaptive programs might settle on alternating between bombing and scanning, with an occasional go at replicating. Until someone comes up with a better replicator that requires rewriting the bomb/scan component. We might see people teaming up, each working to optimize some component of a super-program that goes up under both names. Sounds like fun! Paul Kline pk6811s@acad.drake.edu From: pk6811s@acad.drake.edu Subject: Re: SKI-ICWS: Status - MultiWarrior 94 Date: 1995/06/26 Message-ID: <1995Jun26.113711@acad.drake.edu>#1/1 references: <199506260400.AAA12230@valhalla.stormking.com> newsgroups: rec.games.corewar The Multi-Warrior Hill is dominated by replicators but I suspect if we had all submitted stones first that they would dominate and prevent any replicator from making it on. Paul Kline pk6811s@acad.drake.edu From: jlewisos@aol.com (JLewisOS) Subject: Re: Revolutionary Redcode Changes Date: 1995/06/26 Message-ID: <3smauh$r0b@newsbf02.news.aol.com>#1/1 references: newsgroups: rec.games.corewar :I've been reading this group for some time, and have tried to write :warriors, (none of them worthy of a trial on the hill though) so I know :the drill, so to speak. Anyway, I've been thinking about the same :problems you are addressing now, and I've come to a few conclusions: : :Allowing access to priviliged information sucks big time! :Altering the instruction set sucks as well (programmers adapt quickly) It's not priviliged if both parties can access the information. Altering the instruction set is, IMO, necessary for the creation of new strategies. (BTW, you are a programmer.) :What is needed is a bit more imagination, and please, don't get stuck in :the thought that you're simulating some kind of computer! If complex :programs (ie new ideas kick ass) is what you want, then combat time needs :to be extended. I think a good way of doing this would be to have set, :but different core-, read/writesizes. Then, a program must (well, almost) :move around/replicate around to find it's opponent. Another interresting :thought would be access to absolute address and memory segmentation, so :that when you try to go out of the segment the task dies. Imagination is not the problem. If it were the programs running on the hill (written by the "best" CoreWars has to offer) would be much more varied. Extending combat time won't help deal with programs that SPL, programs are normally in an infinite loop if they reach the end of time anyway. Randomizing Core read/write may force programmer to change strategies but will still suffer from a limited number of strategies. :I also think that mega-process warriors suck. (most of them, anyway) A :good way of killing the "imp-plague" would be to outlaw two processes :running the same code. Note that it would do away with imps without :having any effect on replicators. Outlawing two processes running the same code is nearly impossible from a PMars standpoint. (I guess you *could* kill processes in the exact same location...) I think that "imp-plague" is really too slow to be effective. The need to safe guard from imps is a low priority. :Another thought is that "intelligence" requires analysis, which in turn :requires a lot of reading. As long as you can write as fast as you read, :any serious intelligence is impossible. perhaps some kind of writing :penalty could be implemented. But any such implementation would have to :keep vampires under wraps, and preferably with a well thought-out general :rule. I think rather then restrict the MOV command, make scanning easier. John- From: jls20@hermes.cam.ac.uk (J.L. Skeet) Subject: Re: Revolutionary Redcode Changes Date: 1995/06/26 Message-ID: <3sm54s$212@lyra.csx.cam.ac.uk>#1/1 references: newsgroups: rec.games.corewar In article , Anders Eurenius wrote: >P.s. Somebody objected to the living organism analogy... Read "What is >this Thing Called Love?" by Isaac Asimov! See ya, I've got to bud now! Lots of people seem to want corewar to become more evolutionary : I would say that then, it's not corewar any more - fun though it can be. I would heartily recommend anyone thinking about evolution on computers to read Steven Levy's "Artificial Life". It's what first told me about corewar, and has loads of other examples. Certainly the most interesting book I've read on the topic. Jon From: Anders Eurenius Subject: Re: Revolutionary Redcode Changes Date: 1995/06/26 Message-ID: #1/1 newsgroups: rec.games.corewar I've been reading this group for some time, and have tried to write warriors, (none of them worthy of a trial on the hill though) so I know the drill, so to speak. Anyway, I've been thinking about the same problems you are addressing now, and I've come to a few conclusions: Allowing access to priviliged information sucks big time! Altering the instruction set sucks as well (programmers adapt quickly) What is needed is a bit more imagination, and please, don't get stuck in the thought that you're simulating some kind of computer! If complex programs (ie new ideas kick ass) is what you want, then combat time needs to be extended. I think a good way of doing this would be to have set, but different core-, read/writesizes. Then, a program must (well, almost) move around/replicate around to find it's opponent. Another interresting thought would be access to absolute address and memory segmentation, so that when you try to go out of the segment the task dies. I also think that mega-process warriors suck. (most of them, anyway) A good way of killing the "imp-plague" would be to outlaw two processes running the same code. Note that it would do away with imps without having any effect on replicators. Another thought is that "intelligence" requires analysis, which in turn requires a lot of reading. As long as you can write as fast as you read, any serious intelligence is impossible. perhaps some kind of writing penalty could be implemented. But any such implementation would have to keep vampires under wraps, and preferably with a well thought-out general rule. Does any of this make sense? Anders Eurenius P.s. Somebody objected to the living organism analogy... Read "What is this Thing Called Love?" by Isaac Asimov! See ya, I've got to bud now! From: KOTH Tourney Server Subject: SKI-ICWS: Status - ICWS Tournament Date: 1995/06/26 Message-ID: <199506260400.AAA30143@valhalla.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status See up to the seconds scores at http://www.stormking.com/~koth Current Status of the StormKing Industries Annual ICWS Tournament CoreWar Hill: # %W/ %L/ %T Name Author Score Age 1 61/ 7/ 32 Cannonade Paul Kline 215 25 2 67/ 25/ 8 Agony T Stefan Strack 210 26 3 53/ 39/ 8 xtc stefan roettger 168 30 4 51/ 40/ 9 Smartbomb 4.0 Devin Kilminster 163 23 5 50/ 40/ 9 Smartbomb 4.0 Devin Kilminster 160 24 6 48/ 37/ 15 scissors matthew householder 159 40 7 49/ 41/ 10 Cat v2.0 Tim Scheer 157 22 8 45/ 40/ 15 Smart Bomb 2.2 Devin Kilminster 151 27 9 45/ 40/ 15 stone matthew householder 151 37 10 44/ 47/ 9 Irony v1.0 Brant D. Thomsen 142 29 11 40/ 47/ 13 warrior 42 stefan roettger 132 38 12 36/ 42/ 23 Arschkarte V2.0 Thomas Nitsche 129 2 13 29/ 34/ 37 Logan John Lewis 125 7 14 30/ 41/ 30 Intangible Dwarf 88.3 Campbell Fraser 119 28 15 37/ 55/ 8 doublestorm ii matthew j. chung 119 34 16 33/ 52/ 15 Trap v0.6a Wolfgang Weisser 113 3 17 33/ 52/ 16 Trap v0.6 Wolfgang Weisser 113 4 18 32/ 52/ 16 Trap v0.62 Wolfgang Weisser 113 1 19 27/ 43/ 30 Impetus v1.0 Michael Constant 110 20 20 29/ 50/ 21 paper: a.k.a molerat scott nelson 108 31 21 26/ 44/ 31 Impetus v1.0 Michael Constant 108 21 From: KOTH Tourney Server Subject: SKI-ICWS: Status - Standard Date: 1995/06/26 Message-ID: <199506260400.AAA11193@valhalla.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status See up to the seconds scores at http://www.stormking.com/~koth Current Status of the StormKing Industries Standard KotH CoreWar Hill : # %W/ %L/ %T Name Author Score Age 1 52/ 47/ 1 Unknown Wolfgang Weisser 156 13 2 33/ 15/ 52 Cannonade P.Kline 152 52 3 43/ 35/ 22 Christopher Steven Morrell 150 17 4 46/ 43/ 11 bigproba nandor sieben 149 40 5 32/ 16/ 52 ttti nandor sieben 148 2 6 42/ 38/ 20 Beholder's Eye V1.7 W. Mintardjo 147 96 7 33/ 19/ 48 Blue Funk 88 Steven Morrell 147 16 8 44/ 42/ 14 Iron Gate Wayne Sheppard 146 146 9 34/ 22/ 44 Test Wayne Sheppard 146 41 10 33/ 21/ 46 CAPS KEY IS STUCK AGAIN Steven Morrell 144 18 11 43/ 43/ 13 Dagger v4.1 Michael Constant 143 61 12 31/ 19/ 50 Peace Mr. Jones 143 26 13 28/ 13/ 59 Imps! Imps! Imps! Steven Morrell 142 63 14 38/ 34/ 28 Keystone t21 P.Kline 141 39 15 33/ 26/ 42 Der Zweiter Blitzkrieg Mike Nonemacher 140 47 16 38/ 37/ 25 .T.E.S.T. V0.1 P.E.M & E.C 139 49 17 39/ 41/ 20 Titled Steven Morrell 138 15 18 38/ 43/ 19 Summer Kitten Richard van der Brug 134 42 19 30/ 25/ 46 Hydra Stephen Linhart 134 126 20 7/ 42/ 51 test Anonymous 72 1 21 2/ 98/ 0 Unknown Wolfgang Weisser 7 0 From: KOTH Tourney Server Subject: SKI-ICWS: Status - MultiWarrior 94 Date: 1995/06/26 Message-ID: <199506260400.AAA12230@valhalla.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status See up to the seconds scores at http://www.stormking.com/~koth Current Status of the StormKing Industries Multiwarrior 94 CoreWar Hill: # Name Author Score Age 1 Christmas Tie P.Kline 2888 32 2 TimeScape (1.1) J. Pohjalainen 2621 22 3 Paperone Beppe Bezzi 2477 1 4 B-Panama X Steven Morrell 2473 6 5 nobody special Mike Nonemacher 2435 39 6 Non Plussed Randy Graham 2114 3 7 Paper Dreaming P.Kline 2112 40 8 Shwing! T. H. Davies 1944 16 9 life Nandor Sieben 1906 41 10 Vanilla 1.3 Robert Macrae 1565 44 11 AB Scanner 2.9 Chris Hodson 1144 2 From: pk6811s@acad.drake.edu Subject: Re: More Revolutionary Redcode Changes Date: 1995/06/27 Message-ID: <1995Jun27.090752@acad.drake.edu>#1/1 references: <1995Jun26.120815@acad.drake.edu> <3sn9s8$5gs@newsbf02.news.aol.com> newsgroups: rec.games.corewar jlewisos@aol.com (JLewisOS) writes: >... > bomber, right? Bombers are dumb, scanners are intelligent. Ah! > > :This could be accomplished by adding one privileged word telling you > :whether you won the last round or not, and a small number of memory > :locations that retain their values from one battle to the next (and which > :only you can update). > > I like the idea of a memory between matches, but I think you would just as > easily change strategies at start up randomly. (In fact I think I will >... If all programs on a Hill randomly switch between strategies, they will approach a 50/50/00 score, with ties only occuring when both chose replication in the same round. But once again the 'intelligence' is in the design and not the action. However, if you know you won the last round, what is the 'intelligent' thing to do? Repeat the same strategy of course. And if you lost you should do something different, either adjust step sizes or change strategies or boot or ... Even if you won you might try optimizing a step size. But maybe it's more intelligent to lose five rounds in a row before changing. And if you find yourself losing every round even while rotating strategies, you should change the order of rotation. >... > Unfortunatly you only give the option of switching between states on a win > or lose basis. What might be better is giving the program access to the > win/lose/tie information between matches in the same way you let them > use CORESIZE. I can keep track of everything myself if I have a private memory area to store results, where I can associate win/loss/tie data with every kind of variation my program attempts. We would just add a new operand designator for accessing that memory - 'P'. So MOV.PA would move my private memory word at P to the A operand of the designated core location, and MOV.AP would go the other way. Paul Kline pk6811s@acad.drake.edu From: jlewisos@aol.com (JLewisOS) Subject: Re: More Revolutionary Redcode Changes Date: 1995/06/27 Message-ID: <3spvdq$r3g@newsbf02.news.aol.com>#1/1 references: <1995Jun27.090752@acad.drake.edu> newsgroups: rec.games.corewar :If all programs on a Hill randomly switch between strategies, they will :approach a 50/50/00 score, with ties only occuring when both chose :replication in the same round. But once again the 'intelligence' is in the :design and not the action. : :However, if you know you won the last round, what is the 'intelligent' :thing to do? Repeat the same strategy of course. And if you lost :you should do something different, either adjust step sizes or change :strategies or boot or ... Even if you won you might try optimizing :a step size. But maybe it's more intelligent to lose five rounds in :a row before changing. And if you find yourself losing every round even :while rotating strategies, you should change the order of rotation. Just because you won doesn't mean you should do the same thing next time. Using th Scissors/Paper/Stones analogy; If I win with Paper I probably beat a Stone then... ...that Stone knows it lost and will probably switch to Scissors. ...and I should switch to Stone to beat it! (Ah, but then you say, if I know this is your strategy, I will just become Paper, yes, it's better to be random.) :I can keep track of everything myself if I have a private memory area to :store results, where I can associate win/loss/tie data with every kind :of variation my program attempts. We would just add a new operand :desinator for accessing that memory - 'P'. So MOV.PA would move my :private memory word at P to the A operand of the designated core :location, and MOV.AP would go the other way. I like the idea of a "memory" area where you can store information. John- From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Re: More Revolutionary Redcode Changes Date: 1995/06/27 Message-ID: <1995Jun27.172945.2792@rhodes>#1/1 references: <1995Jun26.120815@acad.drake.edu> newsgroups: rec.games.corewar pk6811s@acad.drake.edu wrote: : I can keep track of everything myself if I have a private memory area to : store results, where I can associate win/loss/tie data with every kind : of variation my program attempts. We would just add a new operand designator : for accessing that memory - 'P'. So MOV.PA would move my private memory : word at P to the A operand of the designated core location, and : MOV.AP would go the other way. I love it. Can this be work out though? How much memory do I get? Any set locations (registers in P-space)?. Then PW, PL, PT, PC has wins, losses, ties, last component run? Or is it my responsibility to track this in my memory, and I can only read W/L/T and component from the last round from general P-space? (do you understand my question). : Paul Kline : pk6811s@acad.drake.edu Randy From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Re: More Revolutionary Redcode Changes Date: 1995/06/27 Message-ID: <1995Jun27.172625.2791@rhodes> references: <1995Jun26.120815@acad.drake.edu> <3sn9s8$5gs@newsbf02.news.aol.com> newsgroups: rec.games.corewar JLewisOS (jlewisos@aol.com) wrote: : :There's no way to make information gathering faster than bombing or : all-out : :replicating. The bombers will just use the scan process to their : :advantage - glorified cmp-scanners. What is needed is something similar : to : :the Prisoner's Dilemma games (see Scientific American's last two issues). : : Yes you can make information gathering faster than bombing and all-out : replicating. I have already given an example: The point Paul was making was that if you did that, your stones woulld just use that method to scan, and then revert to a normal stone attack method. : PRC A,B Where the next instruction is skipped is there is a process : between : the A and B (using the shortest distance between the two) OK, tried this. Here is a rough draft that finds and eliminates one process in less than 100 rounds. ;name half-life ;strategy use PRC to quickly find someone by looking at each half of ;strategy unchecked core. LEN equ (fini-curr_step) ADJ equ (LEN/2) org start curr_step dat.f 4000-ADJ, 4000-ADJ divline dat.f 2, 2 adjust add.f curr_ste, start div.f divline, curr_ste ;can't remember order of DIV sub.b curr_step, start start prc fini+1, fini+4000-ADJ jmp.a adjust zeroin div.f divline, curr_step sub.b curr_step, start slt.b curr_step, #32 jmp.a start attack mov.i spltrap, }start djn.f -1, #32 spltrap spl.a #0, <-64 mov.i 2, {-1 djn.f -1, <-67 dat.f <-65, <-63 fini end start Not sure if I got it coded exactly correctly, but the basic principal should be clear. I scan half of core. If I find something, I look at the lower half of the scan to see if I still find something. If not, I look at the top half of the last chunk in which I found something. In a size 8000 core, I will take 8 or 9 PRC scans to find you. If I miss all the way, that adds about 5 instructions per scan. Thus, worst case of about 50 cycles. Then, 64 more to spl-carpet the whole thing. I defy anything but imp mov.i #0, 1 to be fully running and not defeated by that. The only way to beat this is for someone to come up with a more efficient scan. I agree that making reading quicker or less expensive somehow than writing would encourage more "intelligent" programs, but I don't think PRC is the correct way to do that. : Your second point is lost on me, if it's a CMP-scanner then it's not a : bomber, right? Bombers are dumb, scanners are intelligent. See above. Stones scan and then bomb. Still an easy win. : :This could be accomplished by adding one privileged word telling you : :whether you won the last round or not, and a small number of memory : :locations that retain their values from one battle to the next (and which : :only you can update). : I like the idea of a memory between matches, but I think you would just as : easily change strategies at start up randomly. (In fact I think I will : work : on this tonight.) : You make a great point about RND. We do need a random number generator. Agreed. Giving warriors "memory" is an outstanding idea at first glance. Then the challenge would be optimizing each part of the warrior, and optimizing the messaging. Also, a RND would be nice, but I'm not sure how much use it would be. : :Two highly adaptive programs might settle on alternating between bombing : :and scanning, with an occasional go at replicating. Until someone comes : :up with a better replicator that requires rewriting the bomb/scan : component. : Unfortunatly you only give the option of switching between states on a win : or lose basis. What might be better is giving the program access to the : win/lose/tie information between matches in the same way you let them : use CORESIZE. Yes, keep track of results of all combats so far. Then though, you have the question of how to track it. Do I get wins/losses/ties per component? Or just a win/lose/tie result of last round and my latest running component? I think with some work this may be usable. : John- Randy From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Re: More Revolutionary Redcode Changes Date: 1995/06/28 Message-ID: <1995Jun28.204709.2794@rhodes>#1/1 newsgroups: rec.games.corewar I just accidentally sent a warrior to pizza when I meant to send it to stormking. I know this will end up putting me in the '94 draft hill when I meant to be on the multi-warrior. I was wondering if anyone else had any problems with this? Really, I wanted to ask the hill carriers if the default behavior for a non-existant hill request could be changed to unsuccessful compile because of bad hill identifier instead of compiling for the default hill for that group (on pizza, redcode-94m would return as unsuccessful). I guess using asserts could test this, but I sometimes just change my redcode line and use the same warrior on different hills, and am too lazy to always fix the assert line. Randy From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Re: More Revolutionary Redcode Changes Date: 1995/06/28 Message-ID: <1995Jun28.174542.2793@rhodes> references: <1995Jun27.172625.2791@rhodes> <3ss8oo$fm0@newsbf02.news.aol.com> newsgroups: rec.games.corewar JLewisOS (jlewisos@aol.com) wrote: [Man, this stuff is getting detailed and long...] : :;name half-life : :;strategy use PRC to quickly find someone by looking at each half of : :;strategy unchecked core. : Yes, this is the baseline for core scanners. I have seen CMP-scanners : find me in less than 40 cycles. How many cycles do you think is "fair"? But the difference is, a cmp-scanner MAY find you in 40 cycles. This will zone in on you in a certain MAXIMUM of about 100. And actually, as you stated this could be improved. Add a dozen lines to QScan core in quarters or so. Then, get withit 100 (250 for 55440 core) and QVamp. Then, start a warrior that eventually wipes out the pit you were trapped in. Using this scenario, I can locate and bomb a core location in about 100 rounds. If I get more aggressive in my attack, I could probably find and attack in 60-70 rounds, but I would stand a greater chance of missing a moving target (details are left as an exercise for the reader). : The main problem is that a program can move. If you blindly scan core : and I've bootstraped myself to a location 4000 spaces away you : kill yourself after the bombing run. (you never confirm that you have the : target in the area you bomb with a positive PRC scan) : This isnt to say that it's not a great idea, it was the first application : of the instruction I thought of too, it's just not a lock on win. Well, after the quick PRC scan and attack, how about if I reset my pointers and run again? Or, as you pointed out, before attacking make another PRC check, and if nothing is there, reset or just back up one level until I find them again. The thing here is, with a poorly written scan like mine, I will still find a stationary target in no more than 100 cycles - usually less. : Imagine the fight between a good PRC scanner and the process : building core slammer. Well, the core slammer would win because he only needs 13 cycles to build to max and start running, while I am a minimum of about 40 cycles to find and zero in for the attack. : :Agreed. Giving warriors "memory" is an outstanding idea at first : :glance. Then the challenge would be optimizing each part of the : :warrior, and optimizing the messaging. Also, a RND would be nice, but : :I'm not sure how much use it would be. : Paul's idea about the memory is great. I can think of several other : uses for it as well. As for the RND we could either make a number : between .00001 and .99999 or a number between 1-maxcoresize. I think a RND would be nice, but as Paul points out, it probably wouldn't be to useful. Might be fun. I would need to see a successful warrior uing it before I would put much work in (why be original when you can steal code - the root of the problem, I'd guess). : I'm glad you like Paul's idea. Someday maybe I'll come up with : something you find usable. Well, it isn't that I don't think you have good ideas. What I am looking for is suggestions which allow us to move CoreWar ahead, but not instantly destroy everything we have done already. For example, with Paul's memory and optimizing parts, we are allowed to change based on past fights. So, I have to come up with a way to adjust myself and quickly get started. If I don't do a good enough job, torch or Iron Gate eats me for dinner because I am BIG until I get myself together. So, until optimizations are found for strategy decisions, a lot of good warriors will still beat up on our new, big, multi-select warriors. With the suggestions you have put forward, I feel in a matter of days the current hill would be gone, replaced by a whole new breed. I think without some learning time built in (due to a change giving only a slight advantage over the past), we won't really make full use of a new tool. In other words, let's evolve slowly. Look at how long the '94 hill has run, and an old '88 warrior is still on it, going strong. True the hill is dominated by '94 warriors, but it took a while for the balance to change, and obviously there is one warrior so well written it is still hanging around. Randy : John- From: jlewisos@aol.com (JLewisOS) Subject: Re: More Revolutionary Redcode Changes Date: 1995/06/28 Message-ID: <3ss8op$fm1@newsbf02.news.aol.com>#1/1 references: <1995Jun27.172945.2792@rhodes> newsgroups: rec.games.corewar I love it. Can this be work out though? How much memory do I get? Any set locations (registers in P-space)?. Then PW, PL, PT, PC has wins, losses, ties, last component run? Or is it my responsibility to track this in my memory, and I can only read W/L/T and component from the last round from general P-space? (do you understand my question). I think you should get only a set number of registers. The first three would represent W/L/T. The fourth would be number of rounds in the challenge. The rest of the spaces would be for your own private use! John - From: jlewisos@aol.com (JLewisOS) Subject: Re: More Revolutionary Redcode Changes Date: 1995/06/28 Message-ID: <3ss8oo$fm0@newsbf02.news.aol.com>#1/1 references: <1995Jun27.172625.2791@rhodes> newsgroups: rec.games.corewar :The point Paul was making was that if you did that, your stones woulld :just use that method to scan, and then revert to a normal stone attack :method. I understood Paul's idea. I felt that this made the "bomber" a more intelligent program, something I have been trying to advocate for some time here. :) :OK, tried this. Here is a rough draft that finds and eliminates one :process in less than 100 rounds. : :;name half-life :;strategy use PRC to quickly find someone by looking at each half of :;strategy unchecked core. Yes, this is the baseline for core scanners. I have seen CMP-scanners find me in less than 40 cycles. How many cycles do you think is "fair"? :Not sure if I got it coded exactly correctly, but the basic principal :should be clear. I scan half of core. If I find something, I look at :the lower half of the scan to see if I still find something. If not, :I look at the top half of the last chunk in which I found something. :In a size 8000 core, I will take 8 or 9 PRC scans to find you. If I :miss all the way, that adds about 5 instructions per scan. Thus, :worst case of about 50 cycles. Then, 64 more to spl-carpet the whole :thing. I defy anything but imp mov.i #0, 1 to be fully running and :not defeated by that. The only way to beat this is for someone to :come up with a more efficient scan. I agree that making reading :quicker or less expensive somehow than writing would encourage more :"intelligent" programs, but I don't think PRC is the correct way to do :that. You could actaully speed this process by doing a scan of 1/4 of the core in the beginning with three PRC commands. The main problem is that a program can move. If you blindly scan core and I've bootstraped myself to a location 4000 spaces away you kill yourself after the bombing run. (you never confirm that you have the target in the area you bomb with a positive PRC scan) This isnt to say that it's not a great idea, it was the first application of the instruction I thought of too, it's just not a lock on win. Imagine the fight between a good PRC scanner and the process building core slammer. :Agreed. Giving warriors "memory" is an outstanding idea at first :glance. Then the challenge would be optimizing each part of the :warrior, and optimizing the messaging. Also, a RND would be nice, but :I'm not sure how much use it would be. Paul's idea about the memory is great. I can think of several other uses for it as well. As for the RND we could either make a number between .00001 and .99999 or a number between 1-maxcoresize. :Yes, keep track of results of all combats so far. Then though, you :have the question of how to track it. Do I get wins/losses/ties per :component? Or just a win/lose/tie result of last round and my latest :running component? I think with some work this may be usable. I'm glad you like Paul's idea. Someday maybe I'll come up with something you find usable. John- From: pk6811s@acad.drake.edu Subject: Re: More Revolutionary Redcode Changes Date: 1995/06/28 Message-ID: <1995Jun28.091650@acad.drake.edu>#1/1 references: <1995Jun26.120815@acad.drake.edu> <1995Jun27.172945.2792@rhodes> newsgroups: rec.games.corewar (Randy Graham) writes: >... > : of variation my program attempts. We would just add a new operand designator > : for accessing that memory - 'P'. So MOV.PA would move my private memory > : word at P to the A operand of the designated core location, and > : MOV.AP would go the other way. > I love it. Can this be work out though? How much memory do I get? >... To save pmars code each would get coresize words. Addressing is relative to location 0 in private store - not relative to your core location. And you only get one word per location, you can't store a whole instruction in there :-) Basically at the beginning of each battle I spend some time doing this: - see what strategy I attempted last time - see what the result was - record the strategy/result combination - select a strategy - make a note of what I am trying - go for it Or maybe this: - add the last result to the win/loss/tie bucket - add 1 to round-counter - if round-counter < some number - select the same strategy - else - record the strategy/results combination - select a new strategy - set round-counter to zero - make a note of what I am trying - go for it The second spends less time getting started, risks using a losing strategy for some number of rounds, and gets a more statistically relevant test of the strategy. I'm not sure that selecting strategies at random would be successful. You might have a weak component in there that would give some wins to the 'smart' adapter, causing him to select an appropriate combination that maximizes his wins. In other words, even the 'random' program needs to recognize that one of his components is a weenie. You probably would want a small random or large-period rotation of strategies to prevent an opponent from 'locking in on' your sequence. I can visualize two highly adaptive, well designed programs battling it out. Each substituting attack plans with short runs of wins followed by a flurry of exchanges and ties, followed by more runs, numerous ties (this time do I go for the safe tie, or do I try to sneak in a win, or do I play dumb and sucker him into a bad sequence?) Eventually the one with the better selection of components should succeed. Or maybe you have too many components and a dumb quick-scanner clobbers you :-) Paul Kline pk6811s@acad.drake.edu From: "A HORSE IS A HORSE(UNLESS IT'S A DOG)" Subject: Bad Coder Seeks Help. Date: 1995/06/29 Message-ID: <01HS9D9O4XKI00TOA5@OCVAXA.CC.OBERLIN.EDU>#1/1 newsgroups: rec.games.corewar Well, The subject says it all. I understand the basic concepts, I don't need any help with understanding the difference between an imp and a dwarf or anything like that. My problem is: My code sucks. Anyone else with this problem please respond. Thanks, Paul Huff P.S. Qualifying "sucks" my absolute best programs earn around 50 or so points... From: bezzi@iol.it (Beppe Bezzi) Subject: Re: More Revolutionary Redcode Changes Date: 1995/06/29 Message-ID: <3sv5i6$laq@mikasa.iol.it>#1/1 references: <1995Jun26.120815@acad.drake.edu> <1995Jun27.172945.2792@rhodes> <1995Jun28.091650@acad.drake.edu> newsgroups: rec.games.corewar pk6811s@acad.drake.edu wrote: >Basically at the beginning of each battle I spend some time doing this: > - see what strategy I attempted ... > ....... >........ >........ > - go for it >... >I'm not sure that selecting strategies at random would be successful. You >might have a weak component in there that would give some wins to the >'smart' adapter, causing him to select an appropriate combination that >maximizes his wins. In other words, even the 'random' program needs >to recognize that one of his components is a weenie. That's true but random choice is faster than any smart strategy, at battle start, a "dumb" stone-imp with few "strategic planning" lines: RND (1,2,3) :choose at random one of three CASE 1-stone/imp spiral 2-silk replicator 3-scissor END CASE (are few lines in Redcode assembler too, I don't need a sophisticated random generator to generate 100 random numbers, I can also use a pre-generated array) will begin bombing and launching its imp spiral while my "intelligent" program is evaluating his strategy; if the winning strategy happens to be "Q-scan to catch imps before launch" and I begin too late my Quick (?!?!)-scan is toasted and the same can be said in many other situations. In short, the strategic part of the program will modify only the ORG statement,so, IMHO, not to give an advantage to quick randomness, may be better to leave a "reasonable" (not too long, and fixed) time to "think" and then, if I'm still sitting in my corner, planning next round strategy, the other boxer will reach me and... (I don't know what you say in the USA, Italian expressions are pictoresque. 8-x (smiley with black eyes and broken teeth)) >You probably would want a small random or large-period rotation of >strategies to prevent an opponent from 'locking in on' your sequence. Question: do you think better to let the programmer know the history of the battle (sequence of rounds with results), useful to refine strategy, or is better to let him only guess it, giving the standard win-loss-tie hill's stats? >I can visualize two highly adaptive, well designed programs battling >it out. Each substituting attack plans with short runs of wins followed >by a flurry of exchanges and ties, followed by more runs, numerous >ties (this time do I go for the safe tie, or do I try to sneak in >a win, or do I play dumb and sucker him into a bad sequence?) Eventually >the one with the better selection of components should succeed. That sounds really cool, you can also plan a "win or die" strategy if you are losing, like vampire, or you will try to stall the match when you are winning adding imps or using silk, and don't forget, your opponent knows that you know you are winning :-) >Paul Kline >pk6811s@acad.drake.edu ----- Giuseppe "Beppe" Bezzi bezzi@iol.it From: jlewisos@aol.com (JLewisOS) Subject: Re: More Revolutionary Redcode Changes Date: 1995/06/29 Message-ID: <3stmpq$sf@newsbf02.news.aol.com>#1/1 references: <1995Jun28.174542.2793@rhodes> newsgroups: rec.games.corewar :Well, it isn't that I don't think you have good ideas. What I am :looking for is suggestions which allow us to move CoreWar ahead, but :not instantly destroy everything we have done already. For example, :with Paul's memory and optimizing parts, we are allowed to change based :on past fights. So, I have to come up with a way to adjust myself and :quickly get started. If I don't do a good enough job, torch or Iron :Gate eats me for dinner because I am BIG until I get myself together. :So, until optimizations are found for strategy decisions, a lot of good :warriors will still beat up on our new, big, multi-select warriors. : :With the suggestions you have put forward, I feel in a matter of days :the current hill would be gone, replaced by a whole new breed. I :think without some learning time built in (due to a change giving only :a slight advantage over the past), we won't really make full use of a :new tool. In other words, let's evolve slowly. Look at how long the :'94 hill has run, and an old '88 warrior is still on it, going strong. :True the hill is dominated by '94 warriors, but it took a while for :the balance to change, and obviously there is one warrior so well :written it is still hanging around. I see your point now, I didn't understand it before. You would rather see changes that didn't kill off all the old warriors as soon as they were implemented. Well, I can certainly understand that. Let me re-work some of my ideas with this in mind and post the results a little later. I had some responses to the first two-thirds of your last post, but in light of getting you point on this issue they seem rather academic. My only goal was to make Core Wars more fun. Here is my plan. I think we agree that in order to create new types of warriors we need to change the Standard, right? So as not to invalidate the warriors of the past lets recap who they are... Scissors accurate, dangerous cmp or jmz Paper resiliant spl Stones fast, lucky mov Okay, so we have three basic strategies. Now, starting from scratch lets look at some of the possible instructions and changes. PRC Too powerful in present incarnation. What could we do to make it less powerful? My main reason for liking this instruction is that there is nothing in the current standard which allows you to spot the enemy. The REAL enemy is the process, not the code. It's when you kill the process that you win. Kill any process to win. Too extreme. Makes paper useless. Nearly Forces single process programs. Kill *first* process to win. Interesting idea that we never really touched on. I really like this idea, it keeps the paper viable but doesn't over balance it too much. Might allow PRC to work as an instruction, might not. Queue Scan. Probably too hard to implement. Hard to understand for New players and nothing is worse then being crushed by something you don't understand. I think I am against this one. Allowing access to modify higher functions. Same problem as the Queue Scan. RND I see the main function of the RND statement as a seed for bombers. As such I don't know how much it would affect the play. Could make them "luckier". Register access. Really cool idea that give programs memories. I really like this one. Programmers who don't sleep... no wait... what time is it.. 4:21 am... I better get some sleep and see if any of this makes sense in the morning. John - From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Re: More Revolutionary Redcode Changes Date: 1995/06/29 Message-ID: <1995Jun29.180644.2797@rhodes>#1/1 references: <1995Jun27.172625.2791@rhodes> <3sut2v$et@news-rocq.inria.fr> newsgroups: rec.games.corewar Planar (Damien.Doligez@inria.fr) wrote: : I guess I don't like the idea of analysing past battles all that much. : What I had in mind is to give the warriors some time to analyse : *each other* before starting the battle phase. Well, analysing past battles is really a matter of how things are programmed. There would not be a need for any additions to redcode except the .P modifier (I think). : So I guess I would change your proposal slightly by giving to the : warriors (in the pre-battle phase) the code of their opponent instead : of (or in addition to) a private memory and information about past : battles. Then you could try to guess what kind of warrior the enemy : is by looking at its code as well as past results. Having the code of the opponent really doesn't help much unless we add a .O (for opcode) modifier. Otherwise, All you can effectively get is size, and maybe see if it is paper by looking for consecutive spl lines (although this can be easily avoided by the original paper programmer. : Does it make sense ? Yes, but it won't work, I don't think. The .O modifier was discussed recently, and I think general feeling was it was too hard to figure out, use, or put in a simulator. : -- Planar Randy From: Planar Subject: Re: More Revolutionary Redcode Changes Date: 1995/06/29 Message-ID: <3sut2v$et@news-rocq.inria.fr>#1/1 references: <1995Jun27.172625.2791@rhodes> <3ss8oo$fm0@newsbf02.news.aol.com><1995Jun28.174542.2793@rhodes> <3su6mc$nug@news-rocq.inria.fr> <1995Jun29.124548.2796@rhodes> newsgroups: rec.games.corewar In article <1995Jun29.124548.2796@rhodes>, graham@hal.mathcs.rhodes.edu (Randy Graham) writes: >[good ideas omitted] >Now, I get some time before battle to >see how I did. I have a cmp-scanner start out (because if I don't set >WARRIOR, it is 1). Torch trashes me some number of times (and I >decide how long to wait before changing strategies myself), so I >assume I am fighting a stone. So... I load a stone/imp combo and >fight a while. If he still beats me, I have tracked how I started, >and now a scanner isn't the way to go. I saw he beat me as stone/imp, >so I try paper. I guess I don't like the idea of analysing past battles all that much. What I had in mind is to give the warriors some time to analyse *each other* before starting the battle phase. So I guess I would change your proposal slightly by giving to the warriors (in the pre-battle phase) the code of their opponent instead of (or in addition to) a private memory and information about past battles. Then you could try to guess what kind of warrior the enemy is by looking at its code as well as past results. Does it make sense ? -- Planar From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Re: More Revolutionary Redcode Changes Date: 1995/06/29 Message-ID: <1995Jun29.124548.2796@rhodes>#1/1 references: <1995Jun27.172625.2791@rhodes> newsgroups: rec.games.corewar Planar (Damien.Doligez@inria.fr) wrote: : This gives me a new idea. How about two-phase fights : Well, I had a similar idea, but wanted to mull it over before presenting it. Read on.. : 1st phase, "setup": the core is divided in two halves, one for each : warrior. A warrior can read the whole core, but only write in its own : half. : 2nd phase, "battle": everybody may write everywhere, as in normal core : war. If we add Paul's memory idea, we could add a new "Prebattle" set of cycles. These would only be executed by warriors with the ;prebattle directive. Then, there could be a certain number of cycles to decide what warrior to send out based on results. Say, allow 100 cycles to determine what you want. This allows some analyzing. It ,ay take less (only 20-30, perhaps). Then, you get to set a WARRIOR variable. Set it to 1 by default (so you would always have a default warrior loaded) in pMars, then change it based on past results. During loading, you would have things blocked off: for WARRIOR==1 ;source for a cmp-scanner rof for WARRIOR=2 ;source for a stone rof ... This way, ONLY the portions you have blocked get loaded. The thing I like about this is that it works with current warriors. Torch still loads as Torch, no matter what. Now, I get some time before battle to see how I did. I have a cmp-scanner start out (because if I don't set WARRIOR, it is 1). Torch trashes me some number of times (and I decide how long to wait before changing strategies myself), so I assume I am fighting a stone. So... I load a stone/imp combo and fight a while. If he still beats me, I have tracked how I started, and now a scanner isn't the way to go. I saw he beat me as stone/imp, so I try paper. With this, old warriors still run fine. New warriors can have several components and not worry about exceeding the 100 line limit, because they only have to make sure each block doesn't exceed the limit. It is up to the author to figure out how to change to a successful strategy. Also, it makes the whole stinking hill self-adjusting for every new opponent. Just like "real-life." If something attacks you, and you don't know what it is, you try what you feel is your best counter-attack. If it doesn't work, you adjust based on the results. Finally, it makes it much easier for people to team up. So, if I write a great scanner, and a friend writes a great stone, we both get on the hill. However, we aren't as high up as we would like to be, so we combine, come up with a good pre-battle phase decision algorithm, and we move up the hill by battling sometimes with my scanner, sometimes with his stone. : Of course, that would be the end of quickscanners. In fact, now that : I wrote it down, it looks like an ad-hoc solution to make them : useless, doesn't it ? Your way would. My suggestion still allows quickscanners, and maybe someone could even figure out when their warrior is losing if it tries quickscanning, so they adjust and just use a decoy and boot. Now, the challenge is figuring out a way to do all this and convincing everyone to give it a try. : -- Planar Randy From: 00ncsummers@bsuvc.bsu.edu (El suen~o de razon produce monstros!) Subject: Re: More Revolutionary Redcode Changes Date: 1995/06/29 Message-ID: <1995Jun29.232447.49775@bsuvc.bsu.edu> references: <1995Jun27.172625.2791@rhodes> <3ss8oo$fm0@newsbf02.news.aol.com> <1995Jun28.174542.2793@rhodes> newsgroups: rec.games.corewar In article <1995Jun28.174542.2793@rhodes>, graham@hal.mathcs.rhodes.edu (Randy Graham) writes: > JLewisOS (jlewisos@aol.com) wrote: > : :Agreed. Giving warriors "memory" is an outstanding idea at first > : :glance. Then the challenge would be optimizing each part of the > : :warrior, and optimizing the messaging. I agree, although I feel that a new form of addressing, like P#, instead of a modifier, would be more appropriate. Also, perhaps this should be thought of as MARS's registers. One problem -- how do you do pointers? I have an idea, but that's another post. > Also, a RND would be nice, but > : :I'm not sure how much use it would be. > > I think a RND would be nice, but as Paul points out, it probably > wouldn't be to useful. Might be fun. I would need to see a I agree wholeheartedly. > : I'm glad you like Paul's idea. Someday maybe I'll come up with > : something you find usable. > Well, it isn't that I don't think you have good ideas. What I am > looking for is suggestions which allow us to move CoreWar ahead, but > not instantly destroy everything we have done already. For example, > with Paul's memory and optimizing parts, we are allowed to change based > on past fights. So, I have to come up with a way to adjust myself and > quickly get started. If I don't do a good enough job, torch or Iron > Gate eats me for dinner because I am BIG until I get myself together. > So, until optimizations are found for strategy decisions, a lot of good > warriors will still beat up on our new, big, multi-select warriors. What I think would help is adding a small preproccessing phase of about 60-100 cycles, where the main body of the program cannot be accessed, but p-space and preproccessing space can be accessed. The preproccessing code is not loaded into memory, and it may alter EQU's. For example, suppose on a particular MARS, p-space is mapped as thus: P#0 P#1 P#2 - 16 rounds played last result(3: win, etc.) user defined then here would be some simple startup code: ;redcode-advanced ;name Flash of Intelligence 1.0 ;strategy Try multiple attacks and see what works. ;assert 1 stone EQU 1 paper EQU 2 scissors EQU 3 type EQU rnd(stone, scissors) ; random start warrior type LOAD begin data dat 8, 10 ; you may execute a DAT to finish preproccessing begin jmz selected, P#0 ; if there has been a round mov #0, P#8 ; clear record of good strategies mov #0, P#9 mov #0, P#10 add P#1, P@15 ; add last score to total of current warrior (pointed by ; P#15) add #1, P#15 ; point to round total register add #2, P@15 ; add to total rounds played for this type (aim for a ; high number of wins by doubling apearent total) slt #13, P#0 ; if a small number of rounds have played jmp selected ; gather more data before making choices slt P#2, P#3 ; see if stone has worked mov #1, P#8 ; stone is good slt P#4, P#5 ; see if paper has worked mov #1, P#9 ; paper is good slt P#6, P#7 ; see if scissors are good mov #1, P#10 ; scissors are good jmn P#8, good ; check for any good strategy jmn P#9, good jmn P#10, good jmp selected ; none of the strategies are any good -- use random. good rnd data, P#15 ; select random strategy ; rnd finds a random number between the a and b field ; of the a instruction and places the result in the b ; field of the b instruction jmn finish, P@15 ; if this is a good strategy, use it. jmp good ; otherwise, search again finish sub #7, P#15 ; convert to EQU's at top set type, P#15 ; type now EQUs P#15 ; format: a field EQUs b value. Enclose in quotes for ; iterative substitution. If P#15 was 5, then ; set type, P#15 ; mov type, $5 ; would evaluate ; mov 5, $5 ; however, ; set type, "P#15" ; mov type, $5 ; would evaluate ; mov P#15, $5 selected mul #2, P#15 ; convert EQU's to win counters RUN ORG start for (type == stone) start etc... rof for (type == paper) start etc... rof for (type == scissors) start etc... rof END This was written for simplicity, not speed. There are many optimizations possible, although speed is really not needed. This is fairly weak code -- it finds good, but not necessarily the best, methods. However, it is fairly unpredictable. This discussion is nice, but it it pie-in-the-sky. A field indirection isn't even in the current draft. -- Nathan Summers, Honors Student, BALL STATE UNIVERSITY "It's out of your jurisdiction, and, even if it weren't, we already have a government. It's a democracy. A TRUE democracy! And we don't need or want you, in your dictatorship, to tell us what we can or cannot do!" "Guards! Silence him!" "With pleasure, m'lord!" A button was pressed; the screen went blank. And with that act the country was plunged into a technological dark age." El suen~o de razon produce monstros! From: jlewisos@aol.com (JLewisOS) Subject: Re: Bad Coder Seeks Help. Date: 1995/06/29 Message-ID: <3suiup$4oi@newsbf02.news.aol.com>#1/1 references: <01HS9D9O4XKI00TOA5@OCVAXA.CC.OBERLIN.EDU> newsgroups: rec.games.corewar My code sometimes sucks as well... The best way to improve code is to get the code of someone else and try to beat it. It's easier to figure out how to make wicked code when it's got a specific target. Once you've got that particular program beat your program can probably beat anything in the same class. (Paper/Stone/Scissors) Then it's just a matter of optimizing. But hey, what do I know I'm not even on the hill yet. :( BTW Is there any way to get the code for warriors on the hills? John- From: jlewisos@aol.com (JLewisOS) Subject: Re: More Revolutionary Redcode Changes Date: 1995/06/29 Message-ID: <3svokl$fqq@newsbf02.news.aol.com>#1/1 references: <3sut2v$et@news-rocq.inria.fr> newsgroups: rec.games.corewar :I guess I don't like the idea of analysing past battles all that much. :What I had in mind is to give the warriors some time to analyse :*each other* before starting the battle phase. : :So I guess I would change your proposal slightly by giving to the :warriors (in the pre-battle phase) the code of their opponent instead :of (or in addition to) a private memory and information about past :battles. Then you could try to guess what kind of warrior the enemy :is by looking at its code as well as past results. : :Does it make sense ? : :-- Planar I love this idea. It would be great to be able to look at you opponents code and come up with a strategy for killing it. You might be able to create a special scan for a number that is common in the code. Or you could look at instructions... if we has instruction numeration. John- From: jlewisos@aol.com (JLewisOS) Subject: Re: More Revolutionary Redcode Changes Date: 1995/06/29 Message-ID: <3svokj$fqm@newsbf02.news.aol.com>#1/1 references: <1995Jun29.124548.2796@rhodes> newsgroups: rec.games.corewar I like the idea of pre-Process variables, but I don't like the idea of loading a totally new warrior if you choose to. There should be a penalty for adaptability and that penalty is size. John- From: jlewisos@aol.com (JLewisOS) Subject: Access to higher funtions. Date: 1995/06/29 Message-ID: <3svo4j$fk2@newsbf02.news.aol.com>#1/1 newsgroups: rec.games.corewar What funtions do people want to be able to read or write to? I would like to know how many processes I have running at one time. It would be nice to be able to change strategies when I realize I have lost X processes. Or (although this would be hard without a way to kill them off) to figure out you have been SPL'ed and fix it. For this second reason I would like to ATLEAST have access to my own queue list. That way is I do get SPL'ed I can try to kill my own processes. It would be nice to have access to how many processes your opponent has running. Is there any other higher functions people would like to be able to read? John - From: Planar Subject: Re: More Revolutionary Redcode Changes Date: 1995/06/29 Message-ID: <3su6mc$nug@news-rocq.inria.fr>#1/1 references: <1995Jun27.172625.2791@rhodes> <3ss8oo$fm0@newsbf02.news.aol.com> <1995Jun28.174542.2793@rhodes> newsgroups: rec.games.corewar In article <1995Jun28.174542.2793@rhodes>, graham@hal.mathcs.rhodes.edu (Randy Graham) writes: >on past fights. So, I have to come up with a way to adjust myself and >quickly get started. If I don't do a good enough job, torch or Iron >Gate eats me for dinner because I am BIG until I get myself together. >So, until optimizations are found for strategy decisions, a lot of good >warriors will still beat up on our new, big, multi-select warriors. This gives me a new idea. How about two-phase fights : 1st phase, "setup": the core is divided in two halves, one for each warrior. A warrior can read the whole core, but only write in its own half. 2nd phase, "battle": everybody may write everywhere, as in normal core war. The length of the first phase would be a few hundred cycles. It would give some time to intelligent programs to make some decisions before being clobbered by dumb and fast programs. Of course, that would be the end of quickscanners. In fact, now that I wrote it down, it looks like an ad-hoc solution to make them useless, doesn't it ? -- Planar From: pk6811s@acad.drake.edu Subject: Multi-pass core clear Date: 1995/06/30 Message-ID: <1995Jun30.190220@acad.drake.edu>#1/1 newsgroups: rec.games.corewar Not exactly a Revolutionary Corewar Change :-), but something very useful I have incorporated into Torch is this kind of multi-pass core-clear: gate dat #0,#fin+10 ... wipe dat #-10,fin-gate+2 incr spl #-step,#step ... clr mov @1,>gate fin djn.b -1,{incr Notice that 'clr' uses whatever 'fin' is pointing to for the clear. As the djn at fin comes around it self-decrements so it is no longer pointing at the spl but points to 'wipe' for the dat clear. It will come around again and again, so several passes of different types can be made. Paul Kline pk6811s@acad.drake.edu From: jlewisos@aol.com (JLewisOS) Subject: Keeping the Revolution Organized Date: 1995/06/30 Message-ID: <3t1eod$qqk@newsbf02.news.aol.com>#1/1 newsgroups: rec.games.corewar This is an incomplete list of ideas from this forum. Please e-mail me anything that is new, missed, or misquoted. I would also like to attribute the ideas to people, but I am going to have to do some more research to get that information. John - New Op-code ideas PRC A,B Would scan location A and return the number of processes in that location to B. RND A Would create a random number from 1-8000 and place it at A. New Modifier ideas % Where the number is the register number. New Higher Function changes Prime Process The idea that a program dies when it's first (prime) process is killed. Would reduce ties. Pre-Fight Stage A 100 turn Pre-Fight stage where programs could intelligently plan strategy for the upcoming battle. Needs Register Area to work. Register Area A nonvolatile area where programs can store information that carries over between battles. Could be implemented with or without Pre-Fight Stage. Access Functions The ability for a program to access current information about the core and both fighters while the running. Examples include the number of processes an opponent is running or accessing the amount of time left in a battle (in 10 cycle increments of course) From: pk6811s@acad.drake.edu Subject: Re: More Revolutionary Redcode Changes Date: 1995/06/30 Message-ID: <1995Jun30.164230@acad.drake.edu>#1/1 references: <3sut2v$et@news-rocq.inria.fr> <3svokl$fqq@newsbf02.news.aol.com> newsgroups: rec.games.corewar >... > :So I guess I would change your proposal slightly by giving to the > :warriors (in the pre-battle phase) the code of their opponent instead > :of (or in addition to) a private memory and information about past > :battles. Then you could try to guess what kind of warrior the enemy > :is by looking at its code as well as past results. > : > :Does it make sense ? > : > :-- Planar > It's easily frustrated by putting lots of suitable decoy code in your startup. Like including many copies of paper to fool your opponent into going with a scanner, but while you actually boot a stone. Paul Kline pk6811s@acad.drake.edu From: jlewisos@aol.com (JLewisOS) Subject: Re: More Revolutionary Redcode Changes Date: 1995/06/30 Message-ID: <3t148a$ock@newsbf02.news.aol.com>#1/1 references: <1995Jun29.180644.2797@rhodes> newsgroups: rec.games.corewar :Yes, but it won't work, I don't think. The .O modifier was discussed :recently, and I think general feeling was it was too hard to figure :out, use, or put in a simulator. : :Randy I don't like the .O modifier but I *do* like the idea of a new instruction that returns the "op-code" value at locations A and sends it to B. In general I think adding modifiers is harder to implement and more confusing then adding simple instructions. John-