From: Paul Anderson Subject: Re: 8086 or 8088 based corewar hardware Date: 1996/08/01 Message-ID: <4trekl$t82@unix.newnorth.net>#1/1 references: <4tr2oa$l5d@hpscit.sc.hp.com> newsgroups: rec.games.corewar jbui@scd.hp.com (Joseph Bui) wrote: >Has anyone ever built an 8086 or 8088 (or other processor) based hardware >implementation of corewar? Obviously the instruction set would be defined >by the chips used, and the SPL instruction would be somewhat hard to mimic. > >Well, I just thought it might be neat to see a real core war where bus >errors and other hardware problems could be caused by enemy warriors... >-joe Already been done. Well it was a software emulator of the complete hardware, so not quite the specification you asked about, but the simulation was complete. Emulated the 8088 motherboard specifications down to the chip level and clock requirements. It was a SPICE emulation run on a MAC about 8 years ago to originally simulate instructions required for hardware malfunctions on IBM PC's and potential virus requirements. It was later modified after the 2nd redcode spec to simulate viruses battling viruses on the IBM platform and then redcode specific instructions emultaed by 8088 ASM instructions to cause problems. HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA!!!!!!!!!!!!!!!!!!!!!!!!! From: Jacques Chester Subject: RBML seeks assistance from the EBS. Date: 1996/08/01 Message-ID: <32018815.4446@ozemail.com.au> newsgroups: rec.games.corewar This is a multi-part message in MIME format. --------------AFD4FBA2E03 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ayo choombas; The RBML is currently considering a proposal to create a RBTS - a Robot Battle Tournament Server. RBTS would be an executable program for several OSes, with many features. RBTS was of course inspired by the brilliant KotH initiative. Therefore, it is my mission to ask assistance from the EBS of the ICWS to help us code the RBTS. No prior knowledge of Robot Battle or its gaming language, RSL, is required. Rather, we are seeking server-savvy coders who would be able to code for several platforms in C or C++, and who would be able to integrate RB support. Interested? I've attached the current specs for the RBTS below. If you feel you can help, or better still give me the EBS' official line on this, please contact me. The RBML also wishes to state that it is largely ignorant of Core War(s). RSL is a 3GL, with C-like structure. It is not even remotely related to redcode, though many related games do use assembler-like instructions. Therefore, the RBML would be very pleased if any member of the ICWS or especially the EBS would be interested in finding out more about Robot Battle. Again, contact me, or you can visit the homepage at: http://www.RobotBattle.com/ or the FTP site at ftp://ftp.RobotBattle.com/ Thanks in advance. JC. -- ___ ___ ______ ______ _______ ______ | \ | | | ____| | ____| | | | ___ | Jacques | \ | | | |___ | | | __| | | | | Chester. | |\ \| | | ___| | | | |\ \ | | | | Project | | \ \ | | |___ | |___ | | \ \ | |_| | Manager, |_| \__| |_____| |_____| |_| \_| |_____| MUD Project Contact me at jchester@ozemail.com.au for more info. BIO AVAILABLE ON REQUEST. --------------AFD4FBA2E03 Content-Type: text/plain; charset=us-ascii; name="RBTS.TXT" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="RBTS.TXT" THE ROBOT BATTLE TOURNAMENT SERVER. ------------------------------------------- CONTENTS: 1> Introduction 2> General Features Implementation Issues Major Data Gathering Features Major Debugging Features Continuity Features Pre-Tournament Features Pre-Match Features In-Torunament Features Post-Tournament Features 3> Advanced General Features Language Features Modularity Features Notes and Comments 4> Internet Torunament Features Pre-Torunament Features In-Torunament Features Post-Tounament Features Notes and Comments 5> Updates and errata. 1: INTRODUCTION. At the moment, Robot Battle is heading in the direction of its most major upgrade in quite some time. I mean, of course, version 1.4, which may be sporting much anticipated features ranging from easy access to x,y positions throught to the controversial 'cookie death' of robots. However, the fact remains that RB will remain a 'one user, one computer, one program' setup. Poor Brad has to run the ever growing tournaments in the same tedious and slow fashion as the rest of us mortals. Wouldn't it be nice for Brad to have some of modified version of RB that would somehow simplify the whole trounament process? Or at least, that's what a few sympathetic players and data-hungry programmers have said in the past. I've decided now to try and pull some of these ideas together, along with new ones, to provide a vision of a Robot Battle that could very usefully augment the existing setup, as well as helping to road-test and showcase a host of new ideas for the game and its administration. This is the Robot Battle Tournament Server. RBTS would, ideally, completely automate the task of running a fixed tournament. Also, it would provide options to host 'running' tournaments similar to the ICWS's KotH comps. More about that later. 2: GENERAL FEATURES: Here's a quick review of the general offline RBTS feature set. Most or all of these futures also work in its online mode. Implementation Issues: ---------------------- Unix is a widely used OS on the internet and in powerful workstations that programmers may want to use. By choosing to have a Unix compilation, we open the door to blazingly fast tournaments. Unix versions also widen the market; many universties may be more interested in a programming tool that can be run right of the campus mainframe out of student's accounts rather than off some of the more retrsicted wintel machines. Students, office workers and other people who have access to fast unix machines will also find this a bonus. DOS is still the most commonly used OS on PCs world-wide. Further, it is somewhat faster than windows in *any* implementation (save possibly NT). A DOS implementation of the RBTS can of course then also be run in DOS sessions under versions of windows 3.x and higher. An NT/95 version of RB1.4 is in the works, as I am lead to understand. With NT4.0 and 95, of course, the most obvious bonuses are interface options and 32 bit technology. But beyond this, 95's inherit technical shortcomings and NT4.0's untested OS/GUI coupling may mean that keeping RBTS from these areas for now would be a good idea. Mac OS, like Unix, is a major force in the internet today. Macintoshes represent, for example, a healthy 27% percent of all WWW servers in operation. Also, like the unix and DOS versions, Mac OS is a proven OS. Again, like DOS/Unix, Mac OS will offer superior performance for any given task; thanks to Apple's shift from the older 0x0 chips to the RISC-based PowerPC CPUs. Like 95 and NT4.0, Mac OS offers an excellent interface. Also, Macintoshes have one of the highest programmer-computer ratios in the world, beaten only by some of the more popular implmentations of Unix (BSD & SCO, I think). Major Data Gathering Features: ------------------------------ * Real time, on demand graphical representation of the data. This allows the player/programmer to assess their robot's performance, and also to track down flaws and faults in their robot by monitoring one variable only. * Auto-log output. The RBTS will optionally produce detailed text files of the robot's performance throughout the specified unit of time; turn, game, match or tournament. This ranges from only saving print() outputs through to logging turns when certain event handlers are caller, which lines are visited in sequence etc. Major Debugging Features: ------------------------- * Very accurate speed controls. RBTS will allow the user to set the speed rate in turns per second. This ranges from 1 through 100. * Turn outcome buffering. RBTS will carry a buffer of the outsomes of previous turns. This buffer can be between 10 and 200 long, and it allows the user to 'rewind' for a more detailed analysis. * Match Replay. This option logs the entire turn outcome buffer, allowing the user to replay the same game over and over. It works by describing the energy states and x,y positions of every object on the field in ASCII format. * Real time, on demand textual monitoring of a robot. This allows the user to view in realtime what information is being logged, without having to pause the game. Coupled with accurate speed ratings, this feature is a real boon. Continuity Features: -------------------- * Automatic error correction. To save user time, RBTS will automatically perform many mundane error corrections that arise due to annoying little problems. This will take form in the ability to specify a secondary robot file to use if the first one cannot be compiled - basicly, if a new piece of programming is causing trouble, the RBTS will optionally load a backup file. Also, RBTS can try to correct problems such as missing close brackets. * Pre-test checks. RBTS can pre-test specific sections of a robot (such as event handlers or subroutines) to see if they would cause errors in play. This would be optional, it means basicly trying to go every line of code and executing to see if problems occur. This could be a slow process on large robots. Pre-Tournament Features: ------------------------ * Directory tournaments. RBTS can be shown in which directories to find PRG robots and DST robots, and optionally search a hard drive for prg and dst files and copy them to the specified directories. It can then automatically draw up a tournament roster for either round-robin play, running tournaments, or for point tournament systems. Robots would randomly be grouped into their first sixes, and so forth. * Binary/ASCII error corrections. RBTS will include SA's RBConv utility, to fix errors in both emailed and FTPed RSL files. Corrected files are then saved to disk for the tournament. * Auto-ranking, compliant with HY's system of aces, majors and minors. This wouldn't have to be part of a tournament, although it may be used to provide handicap figures. Pre-Match Features: ------------------- * Precompiling options. RBTS will fully support the SA's RBIFPP, as well as a host of features of its own for so called 'running' torunaments. * Roster upgrading. Depending on the torunament type, RBTS will automatically upgrade its roster based on the previous matches. In-Tournament Features: ----------------------- * Auto-result output. This can be in XLS, DB-IV or ASCII format. * Statistical performance reviews. RBTS can compile and prepare match-by-match reports and comparisons of a robot's on-going and overall performance. * Saved Tournaments. RBTS would be able to use buffer saves to reconstruct a tournament that is in progress. * Multi-tasking. The RBTS would be able to multitask matches locally, and possibly also attempt to use distributed processing across a network of computers. * Anti-randomness system. Optionally (hopefully) , RBTS would be able to combat some of the randomness that is inherit in tournaments. * Handicap scores, according to ranking. Post-Tournament Features: ------------------------- * Participant packages. These packages are internally compressed self-extracting LHA files that can contain all of the data compiled on a robot by the RBTS. This can then be attached to a rating email to a participant. 3: ADVANCED GENERAL FEATURES Ideally, RBTS will support tournaments under any version of the GGL. Therefore, it would mean that RBTS will need to from the start have to support all of the advanced features of RB 1.4 that cover language interperatation. Here's some features to remember: Language Features: ------------------ * LDF file recognition. RBTS will ideally have the ability to accept and compile LDF files. * Java JIT compilation? A possible canidate with regards to web interactivity. Modularity Features: -------------------- * Hopefully RBTS will allow for some sort of 'plug-in' system. This would include things like LDF compiling. Notes and Comments: ------------------- A lot of features listed are debugging and programmer-oriented ones. It logically follows of course that none of them need to be turned on, rather, the tournament can operate as a minimized or backround function, for minimum disruption and maximum speed. This ties in with RBTS' original philosophy; to provide a fully automatic and effecient system of executing RB tournaments. This would be aimed of course at Brad, but also to any other mug with a computer able to execute the program. There would have to be several types of tournaments, of course. To start, there would be the standard, run-of-the-mill type modelled on Brad's current tournaments. These could be run locally or as internet affairs, with the internet side of the server being able to accept entries until a specified time. It could take entries literally to the last minute, collate them and enter them. An entry that arrives five seconds later would theoretically be turned away by the RBTS. The next kind of tournament would be a total score one. This type just ensures that every robot has at least one chance to fight every other. RBTS then tallies each robot's overall score and names a winner based on that. The third kind of tournament is a King of the Hill battle tournament. KotH are 'running' tournaments, which means that they can in theory never end. In KotH, a robot can be submitted at any time and be entered. Robots that are being entered for the first time are played against the top 35 robots in a mini-tournament. The results are then returned to the player. If the new robot scorse better then another one, then that robot's ranking on the Hill is reduced by one (with flow-on demotions) and the new robot is inserted. Running tournaments are based on total points rules. KotH of course is derived from the International Core War Society. Many thanks for their great idea. The next kind of tournament is the 'epic' tournaments. In an epic tournament, robots are placed in a random queue. They are then feeded in one by one. As one robot dies, another takes its place. Every time a robot dies, its contemparies get 10 points for surviving. Scoring in epic tournaments can either be for how long the robot survived in turns (epic survival) or total points scored (epic combat). Using the internet features, running epic tournaments can be run, with each new robot submitted being pitted up against a saved buffer. Hopefully, in future, RBTS will support the RB1.4 large battlefields and unlimited robot options. These will lead to much more interesting epic tournaments. For instance, imagine a running epic combat tournament, on BF 1000x1000 with ten robots. One excellent idea for all torunaments is this: Level playing field tournaments. Robots could be fought against each other according to their rank on HY's chart. This would help to combat the 'newbie massacres' that take place. 4: INTERNET TOURNAMENT FEATURES All of the the features above are for use on a local machine. They can be used by just one user, or for several users holding their own tournament. However, RBTS also boasts a host of features for hosting tournaments via the internet. Specifically, these features will be for Brad, but of course anyone with RBTS will be able to use them. Internet Tournaments can be either round-robin, point, KotH or epics. Pre-Tournament Features: ------------------------ * Automatic entry management. The RBTS will be able to accept FTPed and emailed entries, repair them, place them in the appropiate directory. It can then do all of the pre-tournament features listed above. In-Tournament Features: ----------------------- * Regular updates. Depending on the tournament type, RBTS can periodically post updates to all participants in a tournament. * Progress queries. Participants can email the RBTS program to get the status of their or any other robot. * Real time, live linkup monitoring of robots. This would allow robot submitters to view the torunament in the way that the runner of the RBTS would. Post-Tournament Features: ------------------------- * Result dispatches. RBTS will email all partcipants will post final results for their robot. This may include participant packages. Notes and Comments: ------------------- Tournament submission bots will have to include a lot more data then their conventional counter-parts. Most of this include names, addresses and size, but other information will need to be included. The information I will describe below will apply optionally to any tournament, but they will apply most importantly to internet tournaments. All information has to appear at the beginning of the robot. In PRGs, this means on the first line down, in DSTs, it should appear unscrambled due to the way distrib.exe works. #BEGIN# This commented text tells RBTS that information follows on the immediate lines. #name= This tells RBTS what the author's name is. Optional. #robot= Tells RBTS what to call the robot. Optional. #email= This tells RBTS what the author's prefered email address. This is compulsory for internet submissions. #inc= This tells RBTS the name of a header file that should be included. If the file named is missing, RBTS will email a request for it. There may be as many inc statments as required. #rsl= This tells RBTS what version of RSL was used. This will become relevant as new versions of RB are introduced. #lines= This tells RB how many lines are in the robot. Optional. #rank= This tells the RBTS what ranking your robot has on HY's scale. This is optional to some tournaments. #END# This tells RBTS when the information header ends. An example of a header: #BEGIN# #name=Jacques Chester #robot=Simple Simon 1.1 #email=jchester@ozemail.com.au #inc=kill.h #inc=find.h #rsl=1.3 #lines=435 #rank=minor-d #END# Commenters on the RBML have talked about intergrating the Java language into the RBTS. The reason I like to discuss Java here, then, is specifically in relation to buffer log animation - both on web pages and on local hosts. Ideally, there would be a Java applet that could animate such log files. As one list member noted, it would be quite easy for Java to handle the graphics of RB. A few gifs and what-not would be enough to run an animation, and of course it would be possible to have stand in or default pictures. One very interesting idea is to push the RBTS towards server/client operations. As it stands, the acronym RBTS was taken because the program would run from a server or some sort. However, the idea that RB1.4 could be the 'client' and RBTS the 'server' is an excellent one - I would want then RBTS to support such an arrangement. This leans heavily towards 'request and review' type torunaments, where the submitter of the bot can in real time monitor their bot as well as the tournament runner could. The theory would be that the RB user would log on to their network or the internet, log onto the RBTS and fire up their local copy of RB. This would most likely be 1.4+, Brad's very busy right now as it stands. Infact, this is perhaps a possible networking framework for RB overall - Brad in the help files has talked about some sort of network support, and a RBTS-RB relationship would be perfect. SA could run really good comps off his work machines;). The RB client would not be as empowered as the server operator. They would not be able to pause the torunament, push it back, change the play rate or anything like that. They would be viewers only, though they would have the option of logging the whole thing to file for later dissemenation. 5: UPDATES AND ERRATA This is the second version of the RBTS document, a revision of the first. Think of it as rbtsdoc v0.2 I'm still waiting to hear the word from Brad. I know he's a busy man, but of course he's done this before. I'd just be interested in hearing from the man. One last thing; please, if you can, I'd like any RBTS thread to remain on RBTS for more than two messages. Thanks. --------------------------------------------------------------------- Well, that's it for now. I'd be interested in hearing your ideas and contributions. - JC. --------------AFD4FBA2E03-- From: sd@ecst.csuchico.edu (Alfalfa Male) Subject: Re: ;test option Date: 1996/08/01 Message-ID: <4tr8lt$b28@charnel.ecst.csuchico.edu>#1/1 references: <31FD03F6.41C67EA6@rice.edu> newsgroups: rec.games.corewar In article <31FD03F6.41C67EA6@rice.edu>, kafka wrote: >hey, > could anybody tell me if the new ;test option on pizza is working >yet? If so, how do I use it? Yes, the test command is finally working. To use it, simply put the word "test" at the end of your ;redcode line, the same place you would normally put "quiet" or "verbose". Example: --- ;redcode test ;name testing ;strategy try the "test" command dat #0, #0 end --- It's that simple. Currently it acts almost exactly like normal, the only differences being half as many rounds are fought and the results are discarded after the mail is sent. Thos -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~\/~~\ /~~~\/\ / \ \ / /~\ /~~~~~YY~~~\\ /~~ Thomas "Thos" Davies V \/\ /\ V / V |\/\/| V\ / sd@ecst.csuchico.edu V \ / | / | V Internet Pizza Server \/ | /\ | Member C.W.M. Corewar King of the Hill information |/oo\| CAVE ON Since 1987 http://www.ecst.csuchico.edu/~pizza/koth/ |/\| From: server@news.stormking.com (StormKing ListProc Account) Subject: Re: Something funny happened... Date: 1996/08/01 Message-ID: <199608012118.XAA06616@mercury.daimi.aau.dk>#1/1 newsgroups: rec.games.corewar -> -> I was wondering if anyone could explain this. I took my warrior, T-1, and -> attached a qscan to it, and it went up 20 points. The thing is, I forgot -> to ever actually _call_ the qscan, and the warrior dosn't boot. That's -> wierd. -> -> WARNING: THIS .SIG IS STILL UNDER CONSTRUCTION -> 20 points is a lot for just random changes. Post the code before and after the qscan and I will look at it. Cheers Martin M. Pedersen -- WOODY: How's the world treating you, Mr. Peterson? NORM: Like a baby treats a diaper. from Cheers From: dick@buckosoft.com (Dick Balaska) Subject: Re: A New " America Online"......$19.96\month Unlimited access!!! Date: 1996/08/01 Message-ID: <4tqp73$ptd@client2.news.psi.net>#1/1 references: <4t8q0t$2cr@ns1.autonet.net> <4tc3u2$k@client2.news.psi.net> <4tk7su$gg0@client2.news.psi.net> newsgroups: rec.games.computer.xpilot,rec.games.corewar,rec.games.design,rec.games.diplomacy Keith Lucas wrote: >In article <4tk7su$gg0@client2.news.psi.net>, >Dick Balaska wrote: >>Keith Lucas wrote: >>Don't you be pickin' on Wisconsin. >Sorry -- it was the first state to spring to mind... That's OK. You spelled it correctly (which is better than most yanks) so you get bonus points. >>Never stopped us before. There's a distinct advantage to controlling >>the largest military complex known to exist. >You _control_ your military -- you mean all that stuff is _intended_ ?!?! I'm sorry, you're quite right. Nobody is in charge. Nobody is responsible. But lots of people are highly decorated for it ;) (One time, Al Haig claimed he was in charge, but he was mistaken). If *I* was in charge of the .mil, i would nuke all the spammers, like the "Make money selling phone cards" crap that will be here shortly (currently making the rounds in the graphics and soc.* groups) dik From: jbui@scd.hp.com (Joseph Bui) Subject: 8086 or 8088 based corewar hardware Date: 1996/08/01 Message-ID: <4tr2oa$l5d@hpscit.sc.hp.com>#1/1 newsgroups: rec.games.corewar Has anyone ever built an 8086 or 8088 (or other processor) based hardware implementation of corewar? Obviously the instruction set would be defined by the chips used, and the SPL instruction would be somewhat hard to mimic. Well, I just thought it might be neat to see a real core war where bus errors and other hardware problems could be caused by enemy warriors... -joe From: Ross Morgan-Linial Subject: Something funny happened... Date: 1996/08/01 Message-ID: #1/1 newsgroups: rec.games.corewar I was wondering if anyone could explain this. I took my warrior, T-1, and attached a qscan to it, and it went up 20 points. The thing is, I forgot to ever actually _call_ the qscan, and the warrior dosn't boot. That's wierd. WARNING: THIS .SIG IS STILL UNDER CONSTRUCTION o o o o o o o o o o o o o [][][][][][][][][][][][][] [] [] [] Ross Morgan-Linial [] [] rmorganl@fhcrc.org [] [] [] [][][][][][][][][][][][][] || || __________||________________||_________ |___|___|___|___|___|___|___|___|___|___| |_|___|___|___|___|___|___|___|___|___|_| |___|___|___|___|___|___|___|___|___|___| |_| |_| |_| Tragedy is when I cut my finger. |_| |_| Comedy is when _you_ walk into |_| |_| an open sewer and die. |_| |_| -- Mel Brooks |_| |_|___________________________________|_| |___|___|___|___|___|___|___|___|___|___| |_|___|___|___|___|___|___|___|___|___|_| |___|___|___|___|___|___|___|___|___|___| For a cleaner Usenet, insert this in ~/News/KILL (rn-style newsreaders): /^Newsgroups:.*\,.*\,.*\,.*\,.*\,/h:=:j From: Anton Marsden Subject: Re: P-space problems Date: 1996/08/02 Message-ID: #1/1 references: <30199659.Amiga@r2d2.sci.fi> newsgroups: rec.games.corewar On 30 Jul 1996, Ilmari Karonen wrote: > ldp.f #10, #0 > should become > ldp.f #0, #-1 > However this is not the case. The instruction instead becomes > ldp.f #10, #-1 > It's as if the instruction was LDP.B instead of LDP.F! Is this a bug in > pmars or have I once again misunderstood some feature in '94 code?? PSpace holds only single values, ie. only one field, so ldp.f degenerates into ldp.b. If you were allowed to store both fields in a pspace location (or even an instruction) it would make the game much more interesting but also make pspace much more powerful... perhaps too powerful. X From: "Karen M. Gould" Subject: Re: A New " America Online"......$19.96\month Unlimited access!!! Date: 1996/08/02 Message-ID: <4tsmgm$6qj@lyra.csx.cam.ac.uk>#1/1 references: <4t8q0t$2cr@ns1.autonet.net> <19960726.190221.70@aschamhs.demon.co.uk> <4tc3u2$k@client2.news.psi.net> <4tk7su$gg0@client2.news.psi.net> newsgroups: rec.games.computer.xpilot,rec.games.corewar,rec.games.design,rec.games.diplomacy dick@buckosoft.com (Dick Balaska) wrote: >Keith Lucas wrote: > >>In article <4tc3u2$k@client2.news.psi.net>, >>Dick Balaska wrote: >>>juggler@aschamhs.demon.co.uk (John Wright) wrote: [loads deleted] >Never stopped us before. There's a distinct advantage to controlling >the largest military complex known to exist. > >dik Don't be a complete and utter git ok? Being an American in Cambridge for 4 years, it really makes me sick to see other's yammering on about America this and America that. Doesn't help the image us living long term in Europe have to deal with. Shade XPilot Newbie Manual Editor http://bau2.uibk.ac.at/~erwin/NM/www/ From: loney@abyss.lerc.nasa.gov Subject: Re: ** If anybody could spare a few moments...*** Date: 1996/08/02 Message-ID: <2AUG199608395222@abyss.lerc.nasa.gov>#1/1 references: newsgroups: rec.games.computer.stars,rec.games.computer.ultima-dragons,rec.games.computer.xpilot,rec.games.corewar,rec.games.design,rec.games.diplomacy,rec.games.empire,rec.games.frp.advocacy Well, by the time you have read my follow-up, you probably already have trashed or replied on the original post. Anyway, I'll bet Mirky's mother- in-law that if you replied to this clown below, you will have the great distinction of being put on his mailing list. You will then receive lots of unsolicited e-mail from lots of people that think you have money to throw away. (Like we all have lots of bars in the bank). In article , sgrierson@enterprise.net (Simon Grierson) writes... >Dear Internet Gamers, > >I am currently considering setting up my own Computer and Videogames Mail >order company in the UK - and as part of my business plan, I need to do >some market research and testing, so I thought these newsgroups would be >ideal for that purpose. > >This is strictly not a business solicitation, and is simply for my own >personal use in determining the potential success of such an outfit. > >Just to let you know, I intend to do the following: > >1. Set up and maintain a WWW site dealing in all the latest PC, Mac, >Playstation, Saturn and Nintendo 64 games - with reviews and news relating >to the products I sell. >2. A UK Based Mailorder outfit advertising in Edge magazine, Play +, Sega >Saturn Magazine, and PC Guide - along with various other publications. >3. Inclusion of a free 1 page A5 Newsletter with all orders. >4. Keen prices. > >So, what I�d like to ask you all is to spend just a few moments of your >time to answer a few questions for me: > > >Part I > >1. Where do you currently buy most of your games software? >A) Mailorder, >B) Department stores, >C) Videogames Chain stores, >D) Local Independent traders, >E) Over the Internet. > >2. In rank order, what do you look for MOST when buying software? >A) Lowest price? >B) Trade-in scheme? >C) Good returns policy? >D) Free offers? >E) Reputation of the retailer? > >Part II > >3. Would you buy software from a Secure WWW Biased Videogames mail order >service? Please give reasons why: >A) Yes, >B) No, >C) Depends. > >4. When looking at a Games WWW site, what do you look for most (In Rank >order)? >A) Up to date news? >C) Latest reviews? >D) Lots of screen shots? >E) Demos? >F) Latest use of Netscape/Internet Explorer technology? >G) Access Speeds? > >Part III > >5. Could you name the top ten games you are most likely to buy in the near >future? > >6. What system do you currently have? >Mac (68k/PowerMac), PC (486/Pentium)(DOS/Win95) Playstation >(UK/US/Japanese/other), Saturn (UK/US/Japanese/Other), Nintendo 64, Amiga, >Acorn (RiscPC/Axxxx/Archimedes). > >7. Which machine do you intend to buy, if any? > >8. How much, on average, do you estimate you spend on Games per month? >A) During the first part of the year, >B) During the Summer, >C) DUring the Holiday season. > >9. What do you think of my plans? > > >Notes: >If you want to include any more information that you think might be helpful >to me (Like if your a mail order retailer yourself, and you can provide me >with any valuable information) - I�ll be extremely grateful. > >Thankyou for your time, and I do apologise for this intrusion . If you want >to know more about me - please point your World Wide Web browsers to my >personal homepage at: > >http://www.enterprise.net/sgrierson/ > >Any comments are welcomed! > >Thanks, > >Simon Grierson. >sgrierson@enterprise.net >100407.2075@compuserve.com >http://homepages.enterprise.net/sgrierson/ > > From: Beppe Bezzi Subject: Re: Something funny happened... Date: 1996/08/02 Message-ID: #1/1 newsgroups: rec.games.corewar At 13.58 01/08/96 -0400, you wrote: >I was wondering if anyone could explain this. I took my warrior, T-1, and >attached a qscan to it, and it went up 20 points. The thing is, I forgot >to ever actually _call_ the qscan, and the warrior dosn't boot. That's >wierd. It's sure weird and 20 points are _a_lot_of_points_ the difference beetween being king and being pushed off. I cannot guess any explaination without the code apart the obvious: 'are you SURE you didn't call the qscan' :-) BTW 20 pts are a lot also if you called the qscan > >WARNING: THIS .SIG IS STILL UNDER CONSTRUCTION > > o o o o o o o o o o o o o > [][][][][][][][][][][][][] > [] [] > [] Ross Morgan-Linial [] > [] rmorganl@fhcrc.org [] -Beppe From: sgrierson@enterprise.net (Simon Grierson) Subject: ** If anybody could spare a few moments...*** Date: 1996/08/02 Message-ID: #1/1 newsgroups: rec.games.computer.stars,rec.games.computer.ultima-dragons,rec.games.computer.xpilot,rec.games.corewar,rec.games.design,rec.games.diplomacy,rec.games.empire,rec.games.frp.advocacy Dear Internet Gamers, I am currently considering setting up my own Computer and Videogames Mail order company in the UK - and as part of my business plan, I need to do some market research and testing, so I thought these newsgroups would be ideal for that purpose. This is strictly not a business solicitation, and is simply for my own personal use in determining the potential success of such an outfit. Just to let you know, I intend to do the following: 1. Set up and maintain a WWW site dealing in all the latest PC, Mac, Playstation, Saturn and Nintendo 64 games - with reviews and news relating to the products I sell. 2. A UK Based Mailorder outfit advertising in Edge magazine, Play +, Sega Saturn Magazine, and PC Guide - along with various other publications. 3. Inclusion of a free 1 page A5 Newsletter with all orders. 4. Keen prices. So, what I�d like to ask you all is to spend just a few moments of your time to answer a few questions for me: Part I 1. Where do you currently buy most of your games software? A) Mailorder, B) Department stores, C) Videogames Chain stores, D) Local Independent traders, E) Over the Internet. 2. In rank order, what do you look for MOST when buying software? A) Lowest price? B) Trade-in scheme? C) Good returns policy? D) Free offers? E) Reputation of the retailer? Part II 3. Would you buy software from a Secure WWW Biased Videogames mail order service? Please give reasons why: A) Yes, B) No, C) Depends. 4. When looking at a Games WWW site, what do you look for most (In Rank order)? A) Up to date news? C) Latest reviews? D) Lots of screen shots? E) Demos? F) Latest use of Netscape/Internet Explorer technology? G) Access Speeds? Part III 5. Could you name the top ten games you are most likely to buy in the near future? 6. What system do you currently have? Mac (68k/PowerMac), PC (486/Pentium)(DOS/Win95) Playstation (UK/US/Japanese/other), Saturn (UK/US/Japanese/Other), Nintendo 64, Amiga, Acorn (RiscPC/Axxxx/Archimedes). 7. Which machine do you intend to buy, if any? 8. How much, on average, do you estimate you spend on Games per month? A) During the first part of the year, B) During the Summer, C) DUring the Holiday season. 9. What do you think of my plans? Notes: If you want to include any more information that you think might be helpful to me (Like if your a mail order retailer yourself, and you can provide me with any valuable information) - I�ll be extremely grateful. Thankyou for your time, and I do apologise for this intrusion . If you want to know more about me - please point your World Wide Web browsers to my personal homepage at: http://www.enterprise.net/sgrierson/ Any comments are welcomed! Thanks, Simon Grierson. sgrierson@enterprise.net 100407.2075@compuserve.com http://homepages.enterprise.net/sgrierson/ From: juggler@aschamhs.demon.co.uk (John Wright) Subject: Re: A New " America Online"......$19.96\month Unlimited access!!! Date: 1996/08/03 Message-ID: <19960803.031558.09@aschamhs.demon.co.uk>#1/1 references: <4tc3u2$k@client2.news.psi.net> <4tk7su$gg0@client2.news.psi.net> <4tsmgm$6qj@lyra.csx.cam.ac.uk> newsgroups: rec.games.computer.xpilot,rec.games.corewar,rec.games.design,rec.games.diplomacy "Karen M. Gould": > Cambridge for 4 years, Urm... have you ever been n' played at LaserQuest? ;) Oh and can you get vistors into the Uni computer labs? >;) John. -- jug.gler \'j*g-(*-)l*r\ n [ME jogelour, fr. OE geogelere, fr. OF jogleour, fr. L joc]ulator, fr. joculatus, pp. of joculari 1a: one who performs tricks or acts of magic ... From: Ross Morgan-Linial Subject: Another warrior... Date: 1996/08/03 Message-ID: <3203F3C1.1E6E@fhcrc.org>#1/1 newsgroups: rec.games.corewar Here's another warrior. Ties, Ties, Ties! is a paper with an infinite imp-spiral. The spiral was created independently of Planar's work on them. I did make a slight modification after seeing his, however. Comments, etc. appreciated. ---cut here--- ;redcode-94 ;name Ties, Ties, Ties! (+3) ;author Ross Morgan-Linial ;strategy Paper + infinite imp spiral ;strategy Tinkered with spiral - now ;strategy with increment-stream ;strategy ;strategy Now pswitched with tornado! ;strategy Mabie I'll do okay! ;strategy ;strategy Compact preprimed imp-pump ;strategy fixed ANOTHER bug in the pump... ;strategy will it work NOW? ;strategy ;strategy spiral spl 0, >start-1 ;strategy add.a #2668, launch ;strategy launch jmp imp-2668, <-2 ;strategy imp mov.i #0, 2667 ;strategy mov.i #0, 2667 ;strategy mov.i #0, 2667 ;assert CORESIZE==8000 _PREV equ 111 ;changed start result ldp.ab #0, #0 ldp.a #_PREV, prev sne.ab #0, result add.a #1, prev mod.a #2, prev stp.ab prev, #_PREV prev jmp @0, #paper dat #0, #w1 ;tornado, stolen from Armory-A5 dms equ 25 dmd equ -2500 step equ -45 djnoff equ -2205 bootd equ 1000 ;changed B equ 24 ;boot (mine) dta dat gate, gate+bootd w1 mov }dta, >dta djn -1, #8 add.ab #B, dta mov }dta, >dta djn -1, #9 jmp bombs+bootd+B gate dat -100, 100 dat <-10, <2667 ;anti imp bit dat -4000, djmp-gate+2 stclr spl #-3000, djmp-gate+2 tclear mov @djmp, >gate mov @djmp, >gate djmp djn.b tclear, {stclr dat 0,0 dat 0,0 bombs spl #step, -step ;hit spl start1 sub incr, @b1 stone mov (0*step)+jump2,*(1*step)+jump2 b2 mov bombs, @stone b1 mov bombm, *stone jump2 djn.f start1, -3*step,>-3*step last bombm mov {step, 1 hack for 41 dat 0, 0 rof ;paper module, stolen from Grilled Octopus ;non-booted (of course) dest0 equ 2200 dest1 equ 3740 dest2 equ -1278 ; pmars optimized range equ 933 ; pmars optimized paper SPL spiral SPL.B 1, #0 ;\ SPL.B 1, #0 ;-> generate 8 processes SPL.B 1, #0 ;/ silk SPL.B @0, {dest0 MOV.I }-1, >-1 silk1 SPL.B @0, -1 MOV.I ibomb, }range MOV.I {silk1, dest2 ibomb DAT.F 235, 1 ; STP #2772, #300 ; JMP -1, >-1 dat 0, 0 dat 0, 0 for 6 dat 0, 0 rof ; continuous imp spiral spiral spl 0, >start-1 add.a #2668, launch launch jmp imp-2668, <-2 imp mov.i #2667, *0 mov.i #2667, *0 mov.i #2667, *0 END start From: Ross Morgan-Linial Subject: Here's Versatility Date: 1996/08/03 Message-ID: <3203F21D.2FD@fhcrc.org> newsgroups: rec.games.corewar Okay, I got bored... so I'm posting Versatility 1.5. The switcher is the only original part. The components were taken from successful pspacers. The switcher is a lot more versatile than the way I've used it, and the table could probably (no, could definitely) be compacted. Comments, suggestions, etc. are appreciated. ---cut here--- ;redcode-94 ;name Versatility 1.5 ;author Ross Morgan-Linial ;assert CORESIZE==8000 ;strategy brainwash-resistant table-based ;strategy pspacer with a scanner from Chameleon, a ;strategy paper from Grilled Octopus and tornado 3.0 ;strategy ;strategy I decided the version of tornado from ;strategy Armory was weak... ;kill Versatility ; scanner, stolen from Chameleon dist EQU 66 spread EQU dist*2 stun spl #spread, spread w2 top add stun, scan ;start here scan cmp dist+top, top slt.ab #100, scan djn.f top, <5100 mov sjump, @scan mov stun, w2 on loss DAT #toffs+0, #w1-jump ;w1->w1 on win DAT #toffs+3, #w2-jump ;w1->w2 on tie DAT #toffs+6, #w3-jump ;w2->w3 on loss DAT #toffs+3, #w2-jump ;w2->w2 on win DAT #toffs+3, #w2-jump ;w2->w2 on tie DAT #toffs+0, #w1-jump ;w3->w1 on loss DAT #toffs+6, #w3-jump ;w3->w3 on win endtab DAT #toffs+3, #w2-jump ;w3->w2 on tie ;w1, w2, and w3 (boot points) go here ;paper module, stolen from Grilled Octopus ;non-booted (of course) dest0 equ 2200 dest1 equ 3740 dest2 equ -1278 ; pmars optimized range equ 933 ; pmars optimized w3 paper SPL.B 1, #0 ;\ SPL.B 1, #0 ;-> generate 8 processes SPL.B 1, #0 ;/ silk SPL.B @0, {dest0 MOV.I }-1, >-1 silk1 SPL.B @0, -1 MOV.I ibomb, }range MOV.I {silk1, dest2 ibomb DAT.F <2667, <5334 ;tornado, stolen from Armory-A5 dms equ 25 dmd equ -2500 step equ -45 djnoff equ -2205 bootd equ 1000 ;changed, for my protection B equ 24 ;boot (mine) dta dat gate, gate+bootd w1 mov }dta, >dta djn -1, #8 add.ab #B, dta mov }dta, >dta djn -1, #9 jmp bombs+bootd+B gate dat -100, 100 dat <-10, <2667 ;anti imp bit dat -4000, djmp-gate+2 stclr spl #-3000, djmp-gate+2 tclear mov @djmp, >gate mov @djmp, >gate djmp djn.b clear, {stclr dat 0,0 dat 0,0 bombs spl #step, -step ;hit spl start1 sub incr, @b1 stone mov (0*step)+jump2,*(1*step)+jump2 b2 mov bombs, @stone b1 mov bombm, *stone jump2 djn.f start1, -3*step,>-3*step last bombm mov {step, 1 end start From: "joflor@winnet.com" Subject: Government Funded Sociological Experimentation Continues Date: 1996/08/03 Message-ID: <32042181.25D2@winnet.com>#1/1 newsgroups: rec.games.corewar Government Funded Sociological Experimentation Continues All has been revealed. Usenet is actually a great sociological experiment devised by the U.S. government intelligence community to build dossiers on all who use it, so says a study recently published by the Merillin Institute. There are unsubstantiated rumors that Deja News, Supernews and Alta Vista are actually receiving black project funding from various agencies. The potential success of the study is considered to be a gamble. Some say it is just another one of the government's games. From: Ross Morgan-Linial Subject: Re: Something funny happened... Date: 1996/08/03 Message-ID: #1/1 references: newsgroups: rec.games.corewar On 2 Aug 1996, Beppe Bezzi wrote: // At 13.58 01/08/96 -0400, you wrote: // >I was wondering if anyone could explain this. I took my warrior, T-1, and // >attached a qscan to it, and it went up 20 points. The thing is, I forgot // >to ever actually _call_ the qscan, and the warrior dosn't boot. That's // >wierd. // // It's sure weird and 20 points are _a_lot_of_points_ the difference beetween // being king and being pushed off. Well, it was only about six places... :-) (it was the beginnier hill, tho.) // I cannot guess any explaination without the code apart the obvious: 'are you // SURE you didn't call the qscan' :-) Yes, I'm sure. I think it has to do with the scanners on the hill... it was a large decoy, placed after the rest of my code, which confuses at least one scanner... // BTW 20 pts are a lot also if you called the qscan When a tried a version with a "working" qscan, it got worse. Lost about four places, instead of gaining six :-( // -Beppe WARNING: THIS .SIG IS STILL UNDER CONSTRUCTION o o o o o o o o o o o o o [][][][][][][][][][][][][] [] [] [] Ross Morgan-Linial [] [] rmorganl@fhcrc.org [] [] [] [][][][][][][][][][][][][] For a cleaner Usenet, insert this in ~/News/KILL (rn-style newsreaders): /^Newsgroups:.*\,.*\,.*\,.*\,.*\,/h:=:j From: guenther.garzaner@aon.at (G�nther Garzaner) Subject: I want to have corewar !!! Date: 1996/08/03 Message-ID: <4tv6dl$1er9@pina1.telecom.at>#1/1 newsgroups: rec.games.corewar Who can send me the game corewar. From: Justin Kao <102741.2022@CompuServe.COM> Subject: Ick v1.5 Date: 1996/08/04 Message-ID: <960804232332_102741.2022_GHT103-1@CompuServe.COM> newsgroups: rec.games.corewar This is Ick v1.5, my other core-clear. It mixes up djn & mov like d-clear, but it also has a few spls... The qscan is copied from Yet. Any suggestions/help? Justin ;redcode-94b ;name Ick v1.5 ;author Justin Kao ;assert 1 org scan sep EQU 17 bootdist equ -1500 ORG scan ;begin quick scan space equ (CORESIZE/81) ; Step when scanning for code. qbomb equ 6 ; Step when bombing whatever we found. scan sne.X space*1+bottom, space*3+bottom seq.X space*2+bottom, space*4+bottom mov #space*1+bottom-found, found sne.X space*45+bottom, space*47+bottom seq.X space*46+bottom, space*48+bottom mov #space*45+bottom-found, found sne.X space*65+bottom, space*67+bottom seq.X space*66+bottom, space*68+bottom mov #space*65+bottom-found, found sne.X space*13+bottom, space*15+bottom seq.X space*14+bottom, space*16+bottom mov #space*13+bottom-found, found jmn.B found, found ; Get out early if found something. sne.X space*57+bottom, space*59+bottom seq.X space*58+bottom, space*60+bottom mov #space*57+bottom-found, found sne.X space*33+bottom, space*35+bottom seq.X space*34+bottom, space*36+bottom mov #space*33+bottom-found, found sne.X space*5+bottom, space*7+bottom seq.X space*6+bottom, space*8+bottom mov #space*5+bottom-found, found sne.X space*25+bottom, space*27+bottom seq.X space*26+bottom, space*28+bottom mov #space*25+bottom-found, found jmn.B found, found ; Get out early if found something. sne.X space*17+bottom, space*19+bottom seq.X space*18+bottom, space*20+bottom mov #space*17+bottom-found, found sne.X space*37+bottom, space*39+bottom seq.X space*38+bottom, space*40+bottom mov #space*37+bottom-found, found sne.X space*53+bottom, space*55+bottom seq.X space*54+bottom, space*56+bottom mov #space*53+bottom-found, found jmn.B found, found ; Get out early if found something. sne.X space*9+bottom, space*11+bottom seq.X space*10+bottom, space*12+bottom mov #space*9+bottom-found, found sne.X space*29+bottom, space*31+bottom seq.X space*30+bottom, space*32+bottom mov #space*29+bottom-found, found sne.X space*49+bottom, space*51+bottom seq.X space*50+bottom, space*52+bottom mov #space*49+bottom-found, found jmn.B found, found ; Get out early if found something. sne.X space*21+bottom, space*23+bottom seq.X space*22+bottom, space*24+bottom mov #space*21+bottom-found, found sne.X space*41+bottom, space*43+bottom seq.X space*42+bottom, space*44+bottom mov #space*41+bottom-found, found sne.X space*61+bottom, space*63+bottom seq.X space*62+bottom, space*64+bottom mov #space*61+bottom-found, found jmn.B found, found ; Get out early if found something. jmn.B found, found ; Quick-bomb if found something. jmp warrior ; Execute regular code, because nothing found. add #space, found found jmz.F -1, 0 ; Goto the location where we found something. mov.B found, backwd ; Save this value for use in backward bomb. forward mov.I b1, >found mov.I b2, @found add #(qbomb-1), found jmn.F forward, @found sub #(2*qbomb), backwd ; Don't re-bomb over forward-scan. backwd mov.I b2, 0 mov.I b1, 25, }1 ;28 or 25 ;sep spaces here cc1 spl #25, 1 mov @-1-sep-2, }-1-sep-2 mov @-2-sep-2, }-2-sep-2 djn.f -2, }-3-sep-2 ;bombs b1 spl #2, 0 b2 mov -1, }-1 bottom end From: JKW Subject: Re: I want to have corewar !!! Date: 1996/08/04 Message-ID: <4u2amu$5d2@excelsior.flash.net>#1/1 references: <4tv6dl$1er9@pina1.telecom.at> newsgroups: rec.games.corewar Corewar Web pages are at: http://www.koth.org http://www.ecst.csuchico.edu/~pizza/koth http://pauillac.inria.fr/~doligez/corewar/ The Corewar FTP site is: ftp.csua.berkeley.edu /pub/corewar Newbies should check the FAQ at www.koth.org... it's got language specification, guides, and tutorials. Post questions to rec.games.corewar. All new players are infinitely welcome! The FAQ is also posted weekly to rec.games.corewar, so check back often if you lack Web access. -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ \ -=- http://ccwf.cc.utexas.edu/~ifio452/ -=- / From: SKI Koth Server Subject: SKI-ICWS: Status - MultiWarrior 94 08/05/96 Date: 1996/08/05 Message-ID: <199608050400.AAA14080@odin.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 08/05/96 ****** NOTICE ****** We have changed our name to koth.org ****** NOTICE ****** See up to the second scores and the latest Core War information at : http://www.koth.org/~koth *FAQ* http://www.koth.org/~koth/corewar-faq.html Current Status of the StormKing Industries Multiwarrior 94 CoreWar Hill: Last battle concluded at : Thu Jul 25 21:05:12 EDT 1996 # Name Author Score Age 1 Son of Imp Steven Morrell 5512 41 2 sisyphus Kafka 5486 6 3 Die Hard P.Kline 5481 28 4 Evol Cap -- John Wilkinson 5459 7 5 TJ Maurizio Vittuari 5430 17 6 Super Evol Cap John Wilkinson 5408 5 7 TESTI Maurizio Vittuari 5345 16 8 60% Cotton Wilkinson 5294 24 9 90% Cotton v5c Wilkinson 5261 23 10 Nematode v1.4e Jonathan Stott 5204 1 11 Yet 3mw Justin Kao 3328 0 From: SKI Koth Server Subject: SKI-ICWS: Status - Multiwarrior Experimental 94 08/05/96 Date: 1996/08/05 Message-ID: <199608050400.AAA14085@odin.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 08/05/96 ****** NOTICE ****** We have changed our name to koth.org ****** NOTICE ****** See up to the second scores and the latest Core War information at : http://www.koth.org/~koth *FAQ* http://www.koth.org/~koth/corewar-faq.html Current Status of the StormKing Industries MultiWarrior Experimental 94 CoreWar Hill: Last battle concluded at : Wed Jul 24 03:11:22 EDT 1996 # Name Author Score Age 1 TimeScapeX (0.1) J. Pohjalainen 5677 61 2 This is Test1 Kurt Franke 5677 26 3 jaded M R Bremer 5677 32 4 Fork v0.2-9p/51b Christoph C. Birk 5677 3 5 Evolve X John Wilkinson 5677 1 6 Test2 George Eadon 5654 21 7 Paper8 G. Eadon 5653 27 8 Paperone Beppe Bezzi 5652 46 9 Gluttony J E Long 5630 19 10 Wait A Lot v0.1 Justin Kao 5485 6 11 Saat V2.01 S. Schroeder 5340 15 12 Shwing! T. H. Davies 5329 57 13 Anthill 5 Planar 5143 23 14 life Nandor Sieben 5072 62 15 Pommes-Ketchup V1.35 S. Schroeder 4926 10 16 lifedwarf Nandor Sieben 4920 38 17 Leviathan2 harleyQ2 4768 13 18 Hidden M.C.Diskett Bullfrog 4444 31 19 Variation M-1 Jay Han 4431 8 20 Leviathan harleyQ2 4105 14 21 Bigring Jonathan Stott 3560 2 From: SKI Koth Server Subject: SKI-ICWS: Status - ICWS Tournament 08/05/96 Date: 1996/08/05 Message-ID: <199608050400.AAA14076@odin.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 08/05/96 ****** NOTICE ****** We have changed our name to koth.org ****** NOTICE ****** See up to the second scores and the latest Core War information at : http://www.koth.org/~koth *FAQ* http://www.koth.org/~koth/corewar-faq.html Current Status of the StormKing Industries Annual ICWS Tournament CoreWar Hill: Last battle concluded at : Thu Aug 1 11:14:03 EDT 1996 # %W/ %L/ %T Name Author Score Age 1 43/ 11/ 46 Cannonade Paul Kline 175 94 2 50/ 33/ 17 Miss Carefree Derek Ross 166 26 3 43/ 34/ 23 Giskard v0.5 Ken Mitton 151 67 4 47/ 44/ 9 Agony T Stefan Strack 150 95 5 37/ 28/ 35 Pommes-Ketchup V1.35 S. Schroeder 146 7 6 31/ 16/ 53 Nothing Special G. Eadon 146 9 7 42/ 38/ 21 Old Tire Swing Randy Graham 145 51 8 31/ 19/ 50 Turkey Beppe Bezzi 143 10 9 41/ 41/ 18 Miss Carry Derek Ross 141 58 10 38/ 36/ 27 Yop La Boum v2.1 P.E.M & E.C. 140 24 11 33/ 31/ 36 Big Bang Theory Zul Nadzri 135 3 12 38/ 45/ 16 test88 P.Kline 132 13 13 28/ 25/ 47 One Fat Lady Robert Macrae 131 11 14 38/ 46/ 16 Slaver v1.1i Christoph C. Birk 129 55 15 37/ 48/ 15 Traper3_t Waldemar Bartolik 127 4 16 31/ 38/ 31 Beauty 1000 v 0.0 Pedro 125 1 17 34/ 46/ 20 Illusion Randy Graham 121 53 18 34/ 49/ 17 DoubleStone v0.7 Christoph C. Birk 120 37 19 36/ 56/ 7 xtc stefan roettger 116 99 20 26/ 39/ 35 Chris Steven Morrell 113 16 21 1/ 1/ 2 Beauty 1000 Pedro 6 2 From: SKI Koth Server Subject: SKI-ICWS: Status - ICWS Experimental 94 08/05/96 Date: 1996/08/05 Message-ID: <199608050400.AAA14090@odin.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 08/05/96 ****** NOTICE ****** We have changed our name to koth.org ****** NOTICE ****** See up to the second scores and the latest Core War information at : http://www.koth.org/~koth *FAQ* http://www.koth.org/~koth/corewar-faq.html Current Status of the StormKing Industries ICWS Experimental 94 CoreWar Hill: Last battle concluded at : Thu Jul 25 11:26:51 EDT 1996 # %W/ %L/ %T Name Author Score Age 1 33/ 5/ 63 Evol Cap 4 X John Wilkinson 161 29 2 34/ 14/ 52 Rosebud Beppe 155 8 3 39/ 27/ 33 Falcon v0.3 X Ian Oversby 151 2 4 44/ 38/ 18 Illusion-94/55 Randy Graham 151 11 5 46/ 41/ 13 Tsunami v0.1 Ian Oversby 151 7 6 45/ 42/ 13 Memories Beppe Bezzi 148 36 7 41/ 35/ 25 BigBoy Robert Macrae 146 54 8 43/ 40/ 17 Frontwards v2 Steven Morrell 145 59 9 38/ 34/ 28 Lithium X 8 John K Wilkinson 143 20 10 41/ 42/ 17 Stepping Stone 94x Kurt Franke 141 15 11 39/ 38/ 24 Derision M R Bremer 139 46 12 41/ 45/ 14 Pagan John K W 137 14 13 42/ 49/ 9 S.E.T.I. 4-X JKW 136 30 14 30/ 26/ 44 Variation M-1 Jay Han 135 9 15 29/ 27/ 45 Aleph 1 Jay Han 131 19 16 36/ 45/ 19 Fire Master Xv1 JS Pulido 127 51 17 33/ 38/ 29 Tornado 2.0 x Beppe Bezzi 127 53 18 26/ 28/ 46 Hector 2 Kurt Franke 123 49 19 38/ 56/ 6 dodger component M R Bremer 119 1 20 33/ 50/ 16 Watcher-h Kurt Franke 116 48 21 33/ 50/ 18 Watcher Kurt Franke 116 52 From: SKI Koth Server Subject: SKI-ICWS: Status - Standard 08/05/96 Date: 1996/08/05 Message-ID: <199608050400.AAA14072@odin.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 08/05/96 ****** NOTICE ****** We have changed our name to koth.org ****** NOTICE ****** See up to the second scores and the latest Core War information at : http://www.koth.org/ *FAQ* http://www.koth.org/corewar-faq.html Current Status of the StormKing Industries Standard KotH CoreWar Hill : Last battle concluded at : Thu Aug 1 16:12:54 EDT 1996 # %W/ %L/ %T Name Author Score Age 1 35/ 23/ 42 Yop La Boum v2.1 P.E.M & E.C. 146 45 2 40/ 36/ 24 PacMan v5 David Moore 145 13 3 28/ 19/ 52 CAPS KEY IS STUCK AGAIN Steven Morrell 138 111 4 38/ 40/ 22 Stasis David Moore 137 21 5 25/ 14/ 61 ttti nandor sieben 136 95 6 39/ 45/ 16 Iron Gate Wayne Sheppard 133 239 7 19/ 5/ 76 Evolve '88 John K Wilkinson 133 1 8 23/ 15/ 62 Cannonade P.Kline 132 145 9 24/ 18/ 58 K-test P.E.M 130 17 10 25/ 20/ 55 Hydra Stephen Linhart 130 219 11 36/ 42/ 21 Beholder's Eye V1.7 W. Mintardjo 130 189 12 24/ 19/ 57 Blue Funk 88 Steven Morrell 129 109 13 20/ 12/ 69 Imperfic II John Wilkinson 128 31 14 22/ 17/ 60 Peace Mr. Jones 127 119 15 25/ 24/ 50 Test Wayne Sheppard 126 134 16 31/ 38/ 30 Keystone t21 P.Kline 124 132 17 33/ 44/ 23 Gisela 3G6 Andrzej Maciejczak 123 8 18 26/ 30/ 43 Big Bang Theory Zul Nadzri 123 9 19 30/ 39/ 30 Giskard v0.5 Ken Mitton 121 83 20 30/ 40/ 30 Christopher Stephen Morrell 120 110 21 20/ 58/ 23 Leon Pedro 82 0 From: kafka Subject: Re: ;test option Date: 1996/08/06 Message-ID: <32080C3B.167EB0E7@rice.edu>#1/1 references: <31FD03F6.41C67EA6@rice.edu> <4tr8lt$b28@charnel.ecst.csuchico.edu> newsgroups: rec.games.corewar Alfalfa Male wrote: > Yes, the test command is finally working. To use it, simply put the > word "test" at the end of your ;redcode line, the same place you would thank you. Is there a similar command to switch the status from verbose to quiet, etc.? kafka From: Beppe Bezzi Subject: Core Warrior 41 Date: 1996/08/06 Message-ID: newsgroups: rec.games.corewar .xX$$x. .x$$$$$$$x. d$$$$$$$$$$$ ,$$$$$$$P' `P' , . $$$$$$P' ' .d b $$$$$P b ,$$x ,$$x ,$$x ,$$b $$. Y$$$$' `$. $$$$$$. $$$$$$ $$P~d$. d$$$b d d$$$ `$$$$ ,$$ $$$$$$$b $$$P `$ $$$b.$$b `Y$$$d$d$$$' . . a . a a .aa . a `$$$ ,$$$,$$' `$$$ $$$' ' $$P$XX$' `$$$$$$$$$ .dP' `$'$ `$'$ , $''$ `$'$ `Y$b ,d$$$P `$b,d$P' `$$. `$$. , `$$P $$$' Y $. $ $ $ Y..P $ `$$$$$$$' $$$P' `$$b `$$$P `P `$' `Y'k. $. $. $. $$' $. Issue 41 August 5, 1996 ______________________________________________________________________________ Core Warrior is a weekly newsletter promoting the game of corewar. Emphasis is placed on the most active hills--currently the '94 draft hill and the beginner hill. Coverage will follow where ever the action is. If you have no clue what I'm talking about then check out these five-star internet locals for more information: FAQs are available by anonymous FTP from rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.Z FTP site is: ftp.csua.berkeley.edu /pub/corewar Web pages are at: (Please note new Stormking's address) http://www.koth.org/ ;Stormking http://www.ecst.csuchico.edu/~pizza/koth ;Pizza http://pauillac.inria.fr/~doligez/corewar/ ;Planar Newbies should check the stormking page for the FAQ, language specification, guides, and tutorials. Post questions to rec.games.corewar. All new players are infinitely welcome! If ftp.csua.berkeley.edu is unreachable, you can download pMARS at: Terry's web page--http://www.infi.net/~wtnewton/corewar/ Planar ftp site--ftp://ftp.inria.fr/INRIA/Projects/para/doligez/cw/pmars Fechter ftp site--ftp://members.aol.com/ofechner/corewar A collection of my hints in the first issues is available at: ftp://ftp.volftp.vol.it/pub/pc/msdos/games/solutions/bbhints.zip ______________________________________________________________________________ Greetings. Another very quiet week; summer, Olympic games and Pizza down for the week end are the main causes. Thos implemented the test option to challenge the hill without aging it. From now on aging will become harder and harder --Beppe Bezzi ______________________________________________________________________________ Current Status of the Internet Pizza Server ICWS '94 Draft Hill: Hill Specs: coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 rounds fought: 200 instruction set: ICWS '94 Draft # %W / %L / %T Name Author Score Age 1 37.0/ 20.6/ 42.4 unrequited love kafka 153.5 13 2 44.0/ 35.9/ 20.2 Probe Anton Marsden 152.0 93 3 46.8/ 42.6/ 10.6 Q^2 Miro Anders Ivner 151.0 143 4 37.7/ 24.8/ 37.5 Simple v0.4b Ian Oversby 150.7 44 5 43.8/ 39.7/ 16.5 Goldfinch P.Kline 147.9 34 6 44.1/ 40.6/ 15.3 Blur 2 Anton Marsden 147.6 92 7 28.9/ 12.6/ 58.5 Return Of The Jedimp John K W 145.2 81 8 40.7/ 36.8/ 22.5 T.N.T. pro Maurizio Vittuari 144.6 811 9 43.0/ 41.6/ 15.4 Earthquake v0.2 Bjoern & Ian 144.4 50 10 43.0/ 41.9/ 15.1 myVamp5.4 Paulsson 144.1 141 11 43.5/ 43.1/ 13.4 Mist P.Kline 143.8 33 12 40.7/ 37.8/ 21.4 Test Anton Marsden 143.7 3 13 41.8/ 41.1/ 17.1 Harmony P.Kline 142.5 58 14 31.8/ 21.6/ 46.5 Rosebud Beppe 142.0 766 15 27.7/ 14.2/ 58.1 ompega Steven Morrell 141.2 208 16 39.0/ 38.8/ 22.2 Yogi Bear P.Kline 139.2 297 17 32.9/ 29.2/ 37.9 Pulp v0.2 Ian Oversby 136.6 188 18 29.3/ 22.4/ 48.3 Armory II John K W 136.2 232 19 38.3/ 40.6/ 21.1 Paper, Scissors and Stone David van Dam 136.1 221 20 39.7/ 43.5/ 16.8 Test Sc Ian Oversby 135.8 1 21 38.7/ 41.9/ 19.5 Twister Beppe Bezzi 135.5 547 22 31.0/ 30.8/ 38.1 Jack in the box II Beppe Bezzi 131.3 450 23 26.9/ 24.5/ 48.5 Ties, Ties, Ties! (+3) Ross Morgan-Linial 129.4 10 24 28.3/ 29.2/ 42.5 Forked Lightning 2.0 Philip Kendall 127.3 26 25 4.0/ 0.0/ 0.0 Dura v0.1 Ian Oversby 12.0 122 Weekly age: 26 ( 7 last week, 31 the week before ) New warriors: 4 Turnover/age rate 15% Average age: 186 ( 176 last week, 191 the week before ) Average score: 137 ( 141 last week, 137 the week before ) The top 25 warriors are represented by 13 authors: Oversby with 5(5.5 :-); Kline with 4; Bezzi and Marsden with 3; JKW with 2. King Report: Blur 2 at the beginning, then Simple until Kafka showed down with unrequited love. Few challenges this week too. ______________________________________________________________________________ 94 - What's New # %W / %L / %T Name Author Score Age 1 34.3/ 17.8/ 47.9 unrequited love kafka 150.7 1 6 39.8/ 38.0/ 22.2 Test Anton Marsden 141.7 1 19 38.7/ 43.8/ 17.5 Test Sc Ian Oversby 133.6 1 24 22.4/ 22.3/ 55.2 Ties, Ties, Ties! (+3) Ross Morgan-Linial 122.5 1 A new King: unrequited love. ______________________________________________________________________________ 94 - What's No More # %W / %L / %T Name Author Score Age 26 25.3/ 29.5/ 45.2 unrequited love kafka 121.1 3 26 32.3/ 42.2/ 25.5 Scimitar 2 P.Kline 122.5 139 26 29.5/ 41.6/ 28.9 airBag Paulsson 117.3 126 26 2.5/ 0.3/ 1.2 blue flame c1/10 bjoern guenzel 8.7 72 ______________________________________________________________________________ 94 - What's Old # %W / %L / %T Name Author Score Age 8 40.7/ 36.8/ 22.5 T.N.T. pro Maurizio Vittuari 144.6 811 14 31.8/ 21.6/ 46.5 Rosebud Beppe 142.0 766 21 38.7/ 41.9/ 19.5 Twister Beppe Bezzi 135.5 547 22 31.0/ 30.8/ 38.1 Jack in the box II Beppe Bezzi 131.3 450 Nothing new from the front. Yogi Bear is very near, TNT is in good shape, Twister and Jack are suffering. ______________________________________________________________________________ HALL OF FAME * means the warrior is still active. Pos Name Author Age Strategy 1 Thermite II Robert Macrae 2262 Qscan -> bomber 2 Impfinity v4g1 Planar 1993 Stone/ imp 3 Jack in the box Beppe Bezzi 1620 P-warrior 4 Tornado 3.0 Beppe Bezzi 1567 Bomber 5 Torch t18 P.Kline 1539 Bomber 6 Chameleon Myer R Bremer 1437 P-warrior 7 Frontwards v2 Steven Morrell 1420 One shot scanner 8 Evol Cap 6.6 John Wilkinson 1299 Imp / stone 9 quiz Schitzo 1262 Scanner/ bomber 10 T.N.T. Maurizio Vittuari 1204 Bomber 11 Grilled Octopus v0.5 David Boeren 1154 P-warrior 12 Hazy Shade II John Wilkinson 1102 P-warrior 13 Stepping Stone Kurt Franke 1049 Qscan -> Vampire 14 Iron Gate 1.5 Wayne Sheppard 926 CMP scanner 15 Agony II Stefan Strack 912 CMP scanner 16 Barrage Anton Marsden 876 Qscan -> replicator 17 Blue Funk Steven Morrell 869 Stone/ imp 18 Flurry Anton Marsden 835 Qscan -> pwarrior 19 T.N.T. pro Maurizio Vittuari 811 * Bomber 20 Thermite 1.0 Robert Macrae 802 Qscan -> bomber 21 Blue Funk 3 Steven Morrell 766 Stone/ imp 21 Rosebud Beppe 766* Stone/ imp 23 Night Train Karl Lewin 755 Replicator 24 Mirage 1.5 Anton Marsden 736 Scanner/ bomber 25 Blizzard Anton Marsden 713 Qscan -> replicator T.N.T. pro climbs a slot and Rosebud two, pairing Blue Funk 3. ______________________________________________________________________________ Current Status of the Internet Pizza Server Beginner's Hill: Hill Specs: coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 maximum age: At age 100, warriors are retired. rounds fought: 200 instruction set: ICWS '94 Draft # %W / %L / %T Name Author Score Age 1 53.7/ 24.2/ 22.0 Yet 4b Justin Kao 183.2 80 2 50.8/ 23.6/ 25.6 Versatility 1.5 Ross Morgan-Linial 178.0 70 3 51.2/ 25.6/ 23.2 Ick v1.5 Justin Kao 176.8 26 4 52.9/ 31.3/ 15.8 T-1 w/decoy Ross 174.5 7 5 48.6/ 29.4/ 22.0 Velveeta Shift-F shar 167.9 78 6 46.6/ 36.1/ 17.3 T-1 Ross 157.2 15 7 39.1/ 26.9/ 34.0 Inferno 1.0 Philip Kendall 151.3 93 8 41.4/ 33.1/ 25.4 Vampirism 1.2 Philip Kendall 149.8 1 9 37.1/ 28.8/ 34.1 (-: :-) Ross 145.4 3 10 36.6/ 31.0/ 32.3 TIE Fighter Ross 142.2 2 11 28.8/ 19.6/ 51.6 Microsoft v1.0 Justin Kao 138.0 36 12 27.0/ 18.3/ 54.7 Ties, Ties, Ties! (+3) Ross 135.6 16 13 32.6/ 31.5/ 36.0 Together 0.3 Ilmari Karonen 133.6 4 14 21.0/ 16.4/ 62.7 more testing Anonymous 125.6 64 15 19.4/ 13.6/ 67.0 Nematode v1.4b Jonathan Stott 125.2 77 16 17.0/ 13.7/ 69.3 Nematode v1.4e Jonathan Stott 120.2 44 17 19.9/ 31.5/ 48.6 Fork 4/13 Christoph C. Birk 108.2 97 18 9.5/ 30.1/ 60.4 silkstomp v2.i harleyQ2 88.8 12 19 5.8/ 26.2/ 68.0 Ties Engine Ross 85.4 5 20 8.4/ 32.6/ 59.1 Mama's Boy Robert J. Street 84.2 58 21 8.5/ 50.4/ 41.1 Kill Wasps Ross 66.5 6 22 10.3/ 4.0/ 13.6 Ties and Wasps -s Ross Morgan-Linial 44.7 27 23 9.9/ 7.1/ 3.0 Together 0.2 Ilmari Karonen 32.7 13 24 9.9/ 7.2/ 2.9 Together Ilmari Karonen 32.6 21 25 6.8/ 3.5/ 1.7 TIE Fighter B Ross 22.0 19 26 challenges; Yet is always King. ______________________________________________________________________________ The Hint Sorry no hint this issue. ______________________________________________________________________________ Questions? Concerns? Comments? Complaints? Mail them to people who care. authors: Beppe Bezzi or Myer Bremer or Anton Marsden From: "Bill R." Subject: good corewar program Date: 1996/08/07 Message-ID: <3209364F.1702@midwest.net>#1/1 references: <3203F3C1.1E6E@fhcrc.org> newsgroups: rec.games.corewar I am new to CoreWar,and am wondering,is there a DOS(or Windows) based program for running warriors against each other that has a better display than CoreWar Pro v3.0? -- The Whiz-Kid billr1@midwest.net From: Philip Kendall Subject: Re: ;test option Date: 1996/08/07 Message-ID: #1/1 references: <31FD03F6.41C67EA6@rice.edu> newsgroups: rec.games.corewar Alfalfa Male wrote [Pizza ;test option] >Yes, the test command is finally working. To use it, simply put the >word "test" at the end of your ;redcode line, the same place you would >normally put "quiet" or "verbose". Example: > [snip] > >It's that simple. Currently it acts almost exactly like normal, the >only differences being half as many rounds are fought and the results >are discarded after the mail is sent. > Warning to everybody: ;kill commands in test warriors will still kill things (I've just killed one of my warriors with a test ;-( ). Do people think this is a good idea? Phil -- Philip Kendall (pak21@cam.ac.uk pak21@kendalls.demon.co.uk) From: jbui@scd.hp.com (Joseph Bui) Subject: Rock, Paper, Scissors Date: 1996/08/07 Message-ID: <4uaepv$qhr@hpscit.sc.hp.com>#1/1 newsgroups: rec.games.corewar I've always thought the game was called "Rock, Paper, Scissors." Since I've begun reading corewar literature, I notice that every author seems to use "stone" instead of "rock." I guess it must be a cultural thing, but "stone" just sounds out of place to me. Joe From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 1996/08/07 Message-ID: newsgroups: rec.games.corewar,rec.answers,news.answers Archive-name: games/corewar-faq Last-Modified: 95/10/12 Version: 3.6 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) pmars08s.zip - portable system, ICWS'88 and '94, runs on UNIX, PC, Mac, Amiga. C source archive pmars08s.tar.Z - same as above pmars08.zip - PC executables with graphics display, req 386+ macpmars02.sit.hqx - pMARS executable for Mac (port of version 0.2) buggy, no display MacpMARS1.99a.cpt.hqx - port of v0.8 for the Mac, with display and debugger MacpMARS1.0s.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.8, 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 L2, 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.6 1995/10/12 22:44:37 stst Exp stst $ From: Tim Chapman Subject: Re: Rock, Paper, Scissors Date: 1996/08/08 Message-ID: #1/1 newsgroups: rec.games.corewar On Wed, 7 Aug 1996, Joseph Bui wrote: > I've always thought the game was called "Rock, Paper, Scissors." Since I've > begun reading corewar literature, I notice that every author seems to use > "stone" instead of "rock." I guess it must be a cultural thing, but "stone" > just sounds out of place to me. > > Joe > Here in England its known as Paper, Stone and Scissors. Rock sounds strange to me. :-) Tim From: Philip Kendall Subject: ;kill at Pizza Date: 1996/08/08 Message-ID: #1/1 newsgroups: rec.games.corewar I recently had a few problems submitting this warrior to Pizza - I then changed it simply by deleting the ;kill Vampirism line and it was then accepted - is this because this counts as a 'blank' kill line, or is something more subtle at work? (Any comments on the warrior welcome as well, especially how to beat papers...) Phil -- Philip Kendall (pak21@cam.ac.uk pak21@kendalls.demon.co.uk) ;redcode-94b ;name Vampirism 1.2 ;author Philip Kendall ;strategy Scan with vamp bombs -> spl / repeated dat clear ;strategy 1.2: improved the bomb ;strategy : erased all boot pointers ;strategy : improved the djn-stream ;kill Vampirism ;assert CORESIZE==8000 SCAN1 equ (loop+3*STEP) SEP equ 12 STEP equ 42 STREAM equ (-400+loop) ; this was a bug in 1.1 CSTART equ (pit-ptr) GATE equ (loop-1) BOOT equ 2000 ; how far to boot main code FBOOT equ 2000 ; how much further to boot fang LENGTH equ (last-loop+1) ; how much code to boot loop add.f step,scan ; the scanner scan cmp.i SCAN1,SCAN1-SEP slt.a #(last-scan+SEP),scan djn.f loop,ptr ; spl/repeated dat coreclear mov.i *ptr,>ptr mov.i *ptr,>ptr djn.f clear,GATE ; first line acts as a trigger wash stp.ab #231,#1 spl.a pit,>wash spl.a pit,>GATE spl.a pit,>GATE last jmp.a pit,>GATE fang jmp.a (pit-FBOOT),0 start dummy for LENGTH ; boot most of code mov.i }bptr,>bptr rof add.ab #FBOOT,bptr ; boot the fang mov.i }bptr,>bptr go spl.a (scan+BOOT),<(GATE+BOOT); start the scanner going sub.f bptr,bptr ; erase the boot pointers sub.f go,go bptr dat.f loop,(loop+BOOT) ; and kill the boot process rubbish for (MAXLENGTH-CURLINE) ; fill up space dat.f {(rubbish+100),>((rubbish+100)*2) rof end start From: Ross Morgan-Linial Subject: Re: Rock, Paper, Scissors Date: 1996/08/09 Message-ID: #1/1 references: <4ufo02$163@hpscit.sc.hp.com> newsgroups: rec.games.corewar On 9 Aug 1996, Joseph Bui wrote: // > On Wed, 7 Aug 1996, Joseph Bui wrote: // > > I've always thought the game was called "Rock, Paper, Scissors." Since I've // // Tim Chapman (psyktpc@unix.ccc.nottingham.ac.uk) wrote: // > Here in England its known as Paper, Stone and Scissors. Rock sounds strange // > to me. :-) // // I notice you have a different order (paper beats stone beats scissors) from // me (rock loses to paper loses to scissors). Do you think this is an usan // vs. brit difference, or is it more local? // // I read a SciAm article this summer which described the cycle of dominance // of three types of male lizards (all same species) as the old rock, paper, // scissors game. I was a pretty short article in a sidebar in the April or // May issue, I think. I always used rock, paper, scissors, but since getting into Corewars, I've gotten used to scissors, paper, stone... ------ Ross Morgan-Linial * rmorganl@fhcrc.org It's easier to do a stupid thing stupidly than an intelligent thing intelligently. From: Derek Ross Subject: Re: Rock, Paper, Scissors Date: 1996/08/09 Message-ID: <479@arbroath.win-uk.net>#1/1 newsgroups: rec.games.corewar Why is it Stone-Paper-Scissors but not Rock-Paper-Scissors ? Reason #1 >I've always thought it was paper-rock-scissors, but there aren't any Corewar >programs called rocks.... :-) > >Justin > > Reason #2 Because you sharpen (or blunt) scissors with a grindstone (stone for short) not a grindrock ... Cheers Derek Only the shallow know themselves From: Justin Kao <102741.2022@CompuServe.COM> Subject: Re: Rock, Paper, Scissors Date: 1996/08/09 Message-ID: <960809054757_102741.2022_GHT71-2@CompuServe.COM>#1/1 newsgroups: rec.games.corewar I've always thought it was paper-rock-scissors, but there aren't any Corewar programs called rocks.... :-) Justin From: jwilkinson@mail.utexas.edu Subject: Re: ;test option Date: 1996/08/09 Message-ID: <199608091609.LAA20248@mail.utexas.edu>#1/1 newsgroups: rec.games.corewar >>Warning to everybody: ;kill commands in test warriors will still kill >>things (I've just killed one of my warriors with a test ;-( ). Do people >>think this is a good idea? >> > >NO! I think it's better to disallow ;kill in ';redcode test' submissions. >There is no logic in keeping it working, test has not to modify hill status I agree with Bezzi. The ;test option really shouldn't be something you need to worry about. It should be 'safe.' From: jbui@scd.hp.com (Joseph Bui) Subject: Re: Rock, Paper, Scissors Date: 1996/08/09 Message-ID: <4ufo02$163@hpscit.sc.hp.com>#1/1 references: newsgroups: rec.games.corewar > On Wed, 7 Aug 1996, Joseph Bui wrote: > > I've always thought the game was called "Rock, Paper, Scissors." Since I've Tim Chapman (psyktpc@unix.ccc.nottingham.ac.uk) wrote: > Here in England its known as Paper, Stone and Scissors. Rock sounds strange > to me. :-) I notice you have a different order (paper beats stone beats scissors) from me (rock loses to paper loses to scissors). Do you think this is an usan vs. brit difference, or is it more local? I read a SciAm article this summer which described the cycle of dominance of three types of male lizards (all same species) as the old rock, paper, scissors game. I was a pretty short article in a sidebar in the April or May issue, I think. From: iltzu@sci.fi (Ilmari Karonen) Subject: Re: ;test option Date: 1996/08/09 Message-ID: <08199623.Amiga@sci.fi>#1/1 newsgroups: rec.games.corewar Philip Kendall wrote: >[Pizza ;test option] > >Warning to everybody: ;kill commands in test warriors will still kill >things (I've just killed one of my warriors with a test ;-( ). Do people >think this is a good idea? Actually I think it is. If I want to get my old warriors off the hill, why should I have to submit an extra warrior to do this? (It would IMHO be even better if I could just send in a ;kill command without a warrior, and it would get processed immediately..) I think there should be a warning about this feature, though. -- Ilmari Karonen From: Beppe Bezzi Subject: Re: ;test option Date: 1996/08/09 Message-ID: #1/1 newsgroups: rec.games.corewar At 21.23 07/08/96 -0400, you wrote: >Alfalfa Male wrote > >[Pizza ;test option] > >>Yes, the test command is finally working. To use it, simply put the >>word "test" at the end of your ;redcode line, the same place you would >>normally put "quiet" or "verbose". Example: >> >[snip] >> >>It's that simple. Currently it acts almost exactly like normal, the ... > >Warning to everybody: ;kill commands in test warriors will still kill >things (I've just killed one of my warriors with a test ;-( ). Do people >think this is a good idea? > NO! I think it's better to disallow ;kill in ';redcode test' submissions. There is no logic in keeping it working, test has not to modify hill status >Phil -Beppe From: jwilkinson@mail.utexas.edu Subject: Re: Rock, Paper, Scissors Date: 1996/08/10 Message-ID: <199608100605.BAA25321@mail.utexas.edu>#1/1 newsgroups: rec.games.corewar >> On Wed, 7 Aug 1996, Joseph Bui wrote: >> > I've always thought the game was called "Rock, Paper, Scissors." Since I've > >Tim Chapman (psyktpc@unix.ccc.nottingham.ac.uk) wrote: >> Here in England its known as Paper, Stone and Scissors. Rock sounds strange >> to me. :-) > >I notice you have a different order (paper beats stone beats scissors) from >me (rock loses to paper loses to scissors). Do you think this is an usan >vs. brit difference, or is it more local? > >I read a SciAm article this summer which described the cycle of dominance >of three types of male lizards (all same species) as the old rock, paper, >scissors game. I was a pretty short article in a sidebar in the April or >May issue, I think. Heh heh. I read that article too. Reminded me of Corewars. :) From: rtd@notesguy.com (Rick "The Notes Guy" Dickinson) Subject: Re: Rock, Paper, Scissors Date: 1996/08/10 Message-ID: <4ugkge$k2e@news2.cais.com>#1/1 references: <4ufo02$163@hpscit.sc.hp.com> newsgroups: rec.games.corewar Sharing the wisdom of the ages with those of us reading rec.games.corewar, jbui@scd.hp.com (Joseph Bui) wrote: >> On Wed, 7 Aug 1996, Joseph Bui wrote: >> > I've always thought the game was called "Rock, Paper, Scissors." Since I've >Tim Chapman (psyktpc@unix.ccc.nottingham.ac.uk) wrote: >> Here in England its known as Paper, Stone and Scissors. Rock sounds strange >> to me. :-) >I notice you have a different order (paper beats stone beats scissors) from >me (rock loses to paper loses to scissors). Do you think this is an usan >vs. brit difference, or is it more local? Substituting Rock for Stone, you have described the exact same cyclic sequence: Paper beats Stone (Rock). Stone (Rock) loses to Paper. Stone (rock) beats Scissors. Scissors loses to Stone (rock). Scissors beats Paper. Paper loses to Scissors. >I read a SciAm article this summer which described the cycle of dominance >of three types of male lizards (all same species) as the old rock, paper, >scissors game. I was a pretty short article in a sidebar in the April or >May issue, I think. Scientific American has also done articles on the "democratic paradox", where it is possible to have such cyclic preferences for perfectly good reasons among three candidates (you prefer A to B, B to C, and C to A). - Rick "Martin Gardner fan club" Dickinson Enterprise ArchiTechs | Views expressed on topics unrelated http://www.eArchiTechs.com | to Lotus Notes are not those of my email: rtd@notesguy.com | company, and may not even be mine. From: guenzel@extern.lrz-muenchen.de (Bjoern Guenzel) Subject: Re: Rock, Paper, Scissors Date: 1996/08/10 Message-ID: <4uggev$i2s@sparcserver.lrz-muenchen.de>#1/1 references: <4uaepv$qhr@hpscit.sc.hp.com> newsgroups: rec.games.corewar jbui@scd.hp.com (Joseph Bui) wrote: >I've always thought the game was called "Rock, Paper, Scissors." Since I've >begun reading corewar literature, I notice that every author seems to use >"stone" instead of "rock." I guess it must be a cultural thing, but "stone" >just sounds out of place to me. But isn't it 'paper wraps stone'? I think to wrap a rock into paper sounds weird... In Germany it is also stone, if I remember correctly. >Joe Bjoern From: jwilkinson@mail.utexas.edu Subject: Re: Rock, Paper, Scissors Date: 1996/08/11 Message-ID: <199608112006.PAA30786@mail.utexas.edu>#1/1 newsgroups: rec.games.corewar >>>I read a SciAm article this summer which described the cycle of dominance >>>of three types of male lizards (all same species) as the old rock, paper, >>>scissors game. I was a pretty short article in a sidebar in the April or >>>May issue, I think. >> >>Heh heh. I read that article too. Reminded me of Corewars. :) > >Just wondering how many people got into Corewar _not_ because of SciAm? :-) I think a more interesting question would be how many people who play Corewars do not read Scientific American on a semi-regular basis, and do not also refer to it by the keen-o abbreviation "SciAm." :> From: "Karen M. Gould" Subject: Reply to juggler re: LaserQuest Date: 1996/08/11 Message-ID: <4ukn69$8lp@lyra.csx.cam.ac.uk>#1/1 references: <4tc3u2$k@client2.news.psi.net> <4tk7su$gg0@client2.news.psi.net> <4tsmgm$6qj@lyra.csx.cam.ac.uk> <19960803.031558.09@aschamhs.demon.co.uk> newsgroups: rec.games.computer.xpilot,rec.games.corewar,rec.games.design,rec.games.diplomacy juggler@aschamhs.demon.co.uk (John Wright) wrote: >"Karen M. Gould": > >> Cambridge for 4 years, > > Urm... have you ever been n' played at LaserQuest? ;) Oh and can you >get vistors into the Uni computer labs? >;) > >John. > >-- >jug.gler \'j*g-(*-)l*r\ n [ME jogelour, fr. OE geogelere, fr. OF jogleour, > fr. L joc]ulator, fr. joculatus, pp. of joculari 1a: one who performs > tricks or acts of magic ... Yes, I have been to LaserQuest with a Professor at Welcome CRC and his two sons, 7 and 9 at the time, as well as all their friends who attended their birthday party, and a few o ther supervising adults. It was a blast (heheh bad joke :) and I think it would be good fun to go with a group my own age, since alot of the time was spent helping to defend those young ones who didn't quite have an idea how to shoot their lasers and were getting slaughtered by the older kids :). As far as Uni computer lab access, no I don't have it. Sorry. Shade kmg@mole.bio.cam.ac.uk From: Justin Kao <102741.2022@CompuServe.COM> Subject: Re: Rock, Paper, Scissors Date: 1996/08/11 Message-ID: <960811054458_102741.2022_GHT86-2@CompuServe.COM>#1/1 newsgroups: rec.games.corewar >>I read a SciAm article this summer which described the cycle of dominance >>of three types of male lizards (all same species) as the old rock, paper, >>scissors game. I was a pretty short article in a sidebar in the April or >>May issue, I think. > >Heh heh. I read that article too. Reminded me of Corewars. :) Just wondering how many people got into Corewar _not_ because of SciAm? :-) Justin From: SKI Koth Server Subject: SKI-ICWS: Status - MultiWarrior 94 08/12/96 Date: 1996/08/12 Message-ID: <199608120400.AAA02281@odin.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 08/12/96 ****** NOTICE ****** We have changed our name to koth.org ****** NOTICE ****** See up to the second scores and the latest Core War information at : http://www.koth.org/~koth *FAQ* http://www.koth.org/~koth/corewar-faq.html Current Status of the StormKing Industries Multiwarrior 94 CoreWar Hill: Last battle concluded at : Sun Aug 11 11:30:03 EDT 1996 # Name Author Score Age 1 Super Evol Cap John Wilkinson 5685 5 2 Son of Imp Steven Morrell 5685 41 3 Die Hard P.Kline 5672 28 4 Evol Cap -- John Wilkinson 5672 7 5 TJ Maurizio Vittuari 5672 17 6 90% Cotton v5c Wilkinson 5665 23 7 sisyphus Kafka 5653 6 8 TESTI Maurizio Vittuari 5652 16 9 60% Cotton Wilkinson 5652 24 10 Nematode v1.4e Jonathan Stott 5609 1 11 Test Pedro 1696 0 From: SKI Koth Server Subject: SKI-ICWS: Status - ICWS Experimental 94 08/12/96 Date: 1996/08/12 Message-ID: <199608120400.AAA02292@odin.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 08/12/96 ****** NOTICE ****** We have changed our name to koth.org ****** NOTICE ****** See up to the second scores and the latest Core War information at : http://www.koth.org/~koth *FAQ* http://www.koth.org/~koth/corewar-faq.html Current Status of the StormKing Industries ICWS Experimental 94 CoreWar Hill: Last battle concluded at : Thu Jul 25 11:26:51 EDT 1996 # %W/ %L/ %T Name Author Score Age 1 33/ 5/ 63 Evol Cap 4 X John Wilkinson 161 29 2 34/ 14/ 52 Rosebud Beppe 155 8 3 39/ 27/ 33 Falcon v0.3 X Ian Oversby 151 2 4 44/ 38/ 18 Illusion-94/55 Randy Graham 151 11 5 46/ 41/ 13 Tsunami v0.1 Ian Oversby 151 7 6 45/ 42/ 13 Memories Beppe Bezzi 148 36 7 41/ 35/ 25 BigBoy Robert Macrae 146 54 8 43/ 40/ 17 Frontwards v2 Steven Morrell 145 59 9 38/ 34/ 28 Lithium X 8 John K Wilkinson 143 20 10 41/ 42/ 17 Stepping Stone 94x Kurt Franke 141 15 11 39/ 38/ 24 Derision M R Bremer 139 46 12 41/ 45/ 14 Pagan John K W 137 14 13 42/ 49/ 9 S.E.T.I. 4-X JKW 136 30 14 30/ 26/ 44 Variation M-1 Jay Han 135 9 15 29/ 27/ 45 Aleph 1 Jay Han 131 19 16 36/ 45/ 19 Fire Master Xv1 JS Pulido 127 51 17 33/ 38/ 29 Tornado 2.0 x Beppe Bezzi 127 53 18 26/ 28/ 46 Hector 2 Kurt Franke 123 49 19 38/ 56/ 6 dodger component M R Bremer 119 1 20 33/ 50/ 16 Watcher-h Kurt Franke 116 48 21 33/ 50/ 18 Watcher Kurt Franke 116 52 From: SKI Koth Server Subject: SKI-ICWS: Status - Standard 08/12/96 Date: 1996/08/12 Message-ID: <199608120400.AAA02273@odin.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 08/12/96 ****** NOTICE ****** We have changed our name to koth.org ****** NOTICE ****** See up to the second scores and the latest Core War information at : http://www.koth.org/ *FAQ* http://www.koth.org/corewar-faq.html Current Status of the StormKing Industries Standard KotH CoreWar Hill : Last battle concluded at : Sun Aug 11 10:49:24 EDT 1996 # %W/ %L/ %T Name Author Score Age 1 42/ 35/ 23 PacMan v5 David Moore 150 17 2 32/ 16/ 53 CAPS KEY IS STUCK AGAIN Steven Morrell 148 115 3 34/ 23/ 43 Yop La Boum v2.1 P.E.M & E.C. 146 49 4 28/ 13/ 59 ttti nandor sieben 144 99 5 29/ 17/ 54 K-test P.E.M 141 21 6 28/ 15/ 57 Simple '88 Ian Oversby 141 4 7 25/ 13/ 62 Cannonade P.Kline 138 149 8 27/ 16/ 57 Blue Funk 88 Steven Morrell 137 113 9 30/ 23/ 47 Test Wayne Sheppard 137 138 10 21/ 5/ 75 Evolve '88 John K Wilkinson 137 5 11 40/ 45/ 15 Iron Gate Wayne Sheppard 135 243 12 24/ 15/ 61 Peace Mr. Jones 133 123 13 21/ 11/ 68 Imperfic II John Wilkinson 132 35 14 25/ 20/ 55 Hydra Stephen Linhart 131 223 15 36/ 42/ 22 Beholder's Eye V1.7 W. Mintardjo 131 193 16 36/ 44/ 20 Stasis David Moore 128 25 17 26/ 28/ 45 Big Bang Theory Zul Nadzri 125 13 18 33/ 46/ 22 Gisela 3G6 Andrzej Maciejczak 120 12 19 30/ 41/ 29 Giskard v0.5 Ken Mitton 120 87 20 20/ 72/ 8 Test Pedro 69 1 21 17/ 73/ 10 Minimalist Pedro 61 2 From: SKI Koth Server Subject: SKI-ICWS: Status - Multiwarrior Experimental 94 08/12/96 Date: 1996/08/12 Message-ID: <199608120400.AAA02286@odin.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 08/12/96 ****** NOTICE ****** We have changed our name to koth.org ****** NOTICE ****** See up to the second scores and the latest Core War information at : http://www.koth.org/~koth *FAQ* http://www.koth.org/~koth/corewar-faq.html Current Status of the StormKing Industries MultiWarrior Experimental 94 CoreWar Hill: Last battle concluded at : Wed Jul 24 03:11:22 EDT 1996 # Name Author Score Age 1 TimeScapeX (0.1) J. Pohjalainen 5677 61 2 This is Test1 Kurt Franke 5677 26 3 jaded M R Bremer 5677 32 4 Fork v0.2-9p/51b Christoph C. Birk 5677 3 5 Evolve X John Wilkinson 5677 1 6 Test2 George Eadon 5654 21 7 Paper8 G. Eadon 5653 27 8 Paperone Beppe Bezzi 5652 46 9 Gluttony J E Long 5630 19 10 Wait A Lot v0.1 Justin Kao 5485 6 11 Saat V2.01 S. Schroeder 5340 15 12 Shwing! T. H. Davies 5329 57 13 Anthill 5 Planar 5143 23 14 life Nandor Sieben 5072 62 15 Pommes-Ketchup V1.35 S. Schroeder 4926 10 16 lifedwarf Nandor Sieben 4920 38 17 Leviathan2 harleyQ2 4768 13 18 Hidden M.C.Diskett Bullfrog 4444 31 19 Variation M-1 Jay Han 4431 8 20 Leviathan harleyQ2 4105 14 21 Bigring Jonathan Stott 3560 2 From: iltzu@sci.fi (Ilmari Karonen) Subject: more about pizza test option Date: 1996/08/12 Message-ID: <13199612.Amiga@sci.fi>#1/1 newsgroups: rec.games.corewar Well, I just noticed that I get messages from tests even though my noise level is standard. IMHO tests should only be shown to those who have set 'verbose' on. This is the first test I've seen so far, but if it becomes more common this could become a problem. What do other people think about it? -- Ilmari Karonen From: SKI Koth Server Subject: SKI-ICWS: Status - ICWS Tournament 08/12/96 Date: 1996/08/12 Message-ID: <199608120400.AAA02277@odin.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 08/12/96 ****** NOTICE ****** We have changed our name to koth.org ****** NOTICE ****** See up to the second scores and the latest Core War information at : http://www.koth.org/~koth *FAQ* http://www.koth.org/~koth/corewar-faq.html Current Status of the StormKing Industries Annual ICWS Tournament CoreWar Hill: Last battle concluded at : Thu Aug 1 11:14:03 EDT 1996 # %W/ %L/ %T Name Author Score Age 1 43/ 11/ 46 Cannonade Paul Kline 175 94 2 50/ 33/ 17 Miss Carefree Derek Ross 166 26 3 43/ 34/ 23 Giskard v0.5 Ken Mitton 151 67 4 47/ 44/ 9 Agony T Stefan Strack 150 95 5 37/ 28/ 35 Pommes-Ketchup V1.35 S. Schroeder 146 7 6 31/ 16/ 53 Nothing Special G. Eadon 146 9 7 42/ 38/ 21 Old Tire Swing Randy Graham 145 51 8 31/ 19/ 50 Turkey Beppe Bezzi 143 10 9 41/ 41/ 18 Miss Carry Derek Ross 141 58 10 38/ 36/ 27 Yop La Boum v2.1 P.E.M & E.C. 140 24 11 33/ 31/ 36 Big Bang Theory Zul Nadzri 135 3 12 38/ 45/ 16 test88 P.Kline 132 13 13 28/ 25/ 47 One Fat Lady Robert Macrae 131 11 14 38/ 46/ 16 Slaver v1.1i Christoph C. Birk 129 55 15 37/ 48/ 15 Traper3_t Waldemar Bartolik 127 4 16 31/ 38/ 31 Beauty 1000 v 0.0 Pedro 125 1 17 34/ 46/ 20 Illusion Randy Graham 121 53 18 34/ 49/ 17 DoubleStone v0.7 Christoph C. Birk 120 37 19 36/ 56/ 7 xtc stefan roettger 116 99 20 26/ 39/ 35 Chris Steven Morrell 113 16 21 1/ 1/ 2 Beauty 1000 Pedro 6 2 From: juggler@aschamhs.demon.co.uk (John Wright) Subject: Re: Reply to juggler re: LaserQuest Date: 1996/08/12 Message-ID: <19960812.181323.45@aschamhs.demon.co.uk>#1/1 references: <4tk7su$gg0@client2.news.psi.net> <4tsmgm$6qj@lyra.csx.cam.ac.uk> <19960803.031558.09@aschamhs.demon.co.uk> <4ukn69$8lp@lyra.csx.cam.ac.uk> newsgroups: rec.games.computer.xpilot,rec.games.corewar,rec.games.design,rec.games.diplomacy "Karen M. Gould": > Yes, I have been to LaserQuest with a Professor at Welcome CRC and his two > sons, > 7 and 9 at the time, as well as all their friends who attended their birthday > party, and a few o ther supervising adults. It was a blast (heheh Ah yes. Little kids. Muhahahaha! >;) > bad joke :) and I think it would be good fun to go with a group my own > age, since alot of the time was spent helping to defend those young ones > who didn't quite have an idea how to shoot their lasers and were getting > slaughtered by the older kids :). May have to arrange something. Urm... I hate arranging things. > As far as Uni computer lab access, no I don't have it. Sorry. Darn. I'm having to wait until Xpilot gets ported to the Acorn if I want to play it without having to travel to Coventry to get to a Sparc Station. BFN, John. -- Juggler (dza.gler). late OE. 2. A magician, wizard, sorcerer; a performer of legerdemain; a conjurer OE. 3. transf. and fig. One who deceives by trickery ME. From: Ross Morgan-Linial Subject: Re: P-space problems Date: 1996/08/12 Message-ID: #1/1 references: <30199659.Amiga@r2d2.sci.fi> newsgroups: rec.games.corewar On 30 Jul 1996, Ilmari Karonen wrote: // Does anyone know exactly how the LDP instruction is supposed to behave? // As far as I can see the following instruction, when executed on the // first round, should chnge like this: // // ldp.f #10, #0 // // should become // // ldp.f #0, #-1 // // However this is not the case. The instruction instead becomes // // ldp.f #10, #-1 // // It's as if the instruction was LDP.B instead of LDP.F! Is this a bug in // pmars or have I once again misunderstood some feature in '94 code?? Well, I have no idea what LDP.B is defined to do, but you can't get two numbers out of Pspace at once. Only .a .b .ab .ba will have obvious effects. The reason is to make pswitching take longer, and thus be less profitable. // -- // Ilmari Karonen // // // // ------ Ross Morgan-Linial * rmorganl@fhcrc.org It's easier to do a stupid thing stupidly than an intelligent thing intelligently. From: Ross Morgan-Linial Subject: Re: Rock, Paper, Scissors Date: 1996/08/12 Message-ID: #1/1 references: <960811054458_102741.2022_GHT86-2@CompuServe.COM> newsgroups: rec.games.corewar On 11 Aug 1996, Justin Kao wrote: // Just wondering how many people got into Corewar _not_ because of SciAm? :-) Me! Meee! I got into it because of a book called 'Artificial Life' (great book) - it mentions Corewar as a precursor of several artifical life systems. ------ Ross Morgan-Linial * rmorganl@fhcrc.org It's easier to do a stupid thing stupidly than an intelligent thing intelligently. From: bremermr@cartoon.ecn.purdue.edu (Myer R. Bremer) Subject: Re: Rock, Paper, Scissors Date: 1996/08/12 Message-ID: <4unvde$13d@mozo.cc.purdue.edu>#1/1 references: <960811054458_102741.2022_GHT86-2@CompuServe.COM> <4unqt9$ilj@newsbf02.news.aol.com> newsgroups: rec.games.corewar >In article <960811054458_102741.2022_GHT86-2@CompuServe.COM>, Justin Kao ><102741.2022@CompuServe.COM> writes: > >>Just wondering how many people got into Corewar _not_ because of SciAm? >:-) > greetings. i had never heard of the sci am articles. my browser in nextstep shows all newgroups in 'browse' mode and i just stumbled across it. i lurked for over a year before i decided to try my luck at the hills. m r bremer From: jxidus@aol.com (JXidus) Subject: Re: Rock, Paper, Scissors Date: 1996/08/12 Message-ID: <4unqt9$ilj@newsbf02.news.aol.com>#1/1 references: <960811054458_102741.2022_GHT86-2@CompuServe.COM> newsgroups: rec.games.corewar In article <960811054458_102741.2022_GHT86-2@CompuServe.COM>, Justin Kao <102741.2022@CompuServe.COM> writes: >Just wondering how many people got into Corewar _not_ because of SciAm? :-) I did... found out about it by getting a Corewar program from some games FTP site... Had to ask someone what the heck it was, 'cause I had never heard of it. :) Of course, you could argue that I'm not really -into- it, since I'm not on any of the KotH hills... ::shrug:: Jeremy Weatherford jxidus@aol.com --- Looking for a quick and easy way to 'fly' a 'camera' around your OGl scene? Contact me at the above address for info on the CAM module, v1.1. From: bremermr@cartoon.ecn.purdue.edu (Myer R. Bremer) Subject: Core Warrior Date: 1996/08/12 Message-ID: <4um0v6$7b0@mozo.cc.purdue.edu>#1/1 newsgroups: rec.games.corewar greetings. since there has only been about 4 challenges to the hill since last issue, i'm going to delay this issue for a week. school's starting up next monday (at least for purdue university) so maybe we'll have some traffic when the kiddies come back. everyone must be pretty lazy at this time of year . . . m r bremer From: Erwin Hugo Achermann Subject: Re: P-space problems Date: 1996/08/13 Message-ID: <199608130639.IAA14501@ru10.inf.ethz.ch>#1/1 newsgroups: rec.games.corewar > It's easier to do a stupid thing stupidly than an intelligent thing > intelligently. Even harder is to do a stupid thing intelligently. :) Erwin Achermann From: bremermr@cartoon.ecn.purdue.edu (Myer R. Bremer) Subject: Re: more about pizza test option Date: 1996/08/13 Message-ID: <4uqm30$4c@mozo.cc.purdue.edu>#1/1 references: <13199612.Amiga@sci.fi> newsgroups: rec.games.corewar In article <13199612.Amiga@sci.fi>, Ilmari Karonen wrote: >Well, I just noticed that I get messages from tests even though my >noise level is standard. IMHO tests should only be shown to those who >have set 'verbose' on. This is the first test I've seen so far, but if >it becomes more common this could become a problem. What do other >people think about it? > >-- >Ilmari Karonen > greetings. i second that. all ;test challenges should only go to verbose modes. not to put any pressure on thos, but where's that ;fight option to challenge one warrior only (or groups of warriors)? i hope that will eventually get implemented. sidelight: when i go to post a message with my newsreader, i get this dire warning that it will cost thousands of dollars, etc etc . . . then it says: are you sure you want to do this? that message kept me from posting in a newgroup for almost a year. relevance? none thank you. m r bremer From: jbui@scd.hp.com (Joseph Bui) Subject: Re: Rock, Paper, Scissors Date: 1996/08/13 Message-ID: <4uqfu1$f2g@hpscit.sc.hp.com>#1/1 references: <4ufo02$163@hpscit.sc.hp.com> <4ugkge$k2e@news2.cais.com> newsgroups: rec.games.corewar This is a short comment about the order of rock/stone, paper, scissors. Rick "The Notes Guy" Dickinson (rtd@notesguy.com) wrote: > Substituting Rock for Stone, you have described the exact same cyclic > sequence: > Paper beats Stone (Rock). Stone (Rock) loses to Paper. > Stone (rock) beats Scissors. Scissors loses to Stone (rock). > Scissors beats Paper. Paper loses to Scissors. Yes, I realize there is no effective difference. I was just wondering about the cultural implications. I remember playing the rock/stone, paper, scissors game when I was about 7 or so, and getting into a fair amount of trouble (it was at the dinner table in a nice restaurant, and we were banging loudly on the table saying "ROCK PAPER SCISSORS " and then displaying your choice. I'd like to note that the other player was an adult at the time. I just wonder if there is some reason that the original order (which ever it is) was changed into a new order, and why (for English speakers) "rock" or "stone" was changed to the other word. Pretty minor, eh? Well, it certainly sounds (reads) funny to me using another order or word, and I thought I'd mention it. Besides, this isn't a very high traffic newsgroup, so I hope no one minds the spam. Joe Bui From: pl436000@brownvm.brown.edu (Jamie Dreier) Subject: Re: Reply to juggler re: LaserQuest Date: 1996/08/13 Message-ID: #1/1 references: <4tk7su$gg0@client2.news.psi.net> <19960803.031558.09@aschamhs.demon.co.uk> <4ukn69$8lp@lyra.csx.cam.ac.uk> <19960812.181323.45@aschamhs.demon.co.uk> <4uphkp$18n@lyra.csx.cam.ac.uk> newsgroups: rec.games.computer.xpilot,rec.games.corewar,rec.games.design Could we get rec.games.diplomacy out of the distribution list for this thread, please? Thanks. In article <4uphkp$18n@lyra.csx.cam.ac.uk>, tjwh1@mrao.cam.ac.uk (Toby Haynes) wrote: > In article <19960812.181323.45@aschamhs.demon.co.uk>, > John Wright wrote: > >"Karen M. Gould": > >> Yes, I have been to LaserQuest with a Professor at Welcome CRC and his two > >> sons, > >> 7 and 9 at the time, as well as all their friends who attended their birthday > >> party, and a few o ther supervising adults. It was a blast (heheh > > Ah yes. Little kids. Muhahahaha! >;) > [snip] > > May have to arrange something. Urm... I hate arranging things. > > Well - if you are going to have a Xpilot Laserquest session in > Cambridge, count me in! > > > Darn. I'm having to wait until Xpilot gets ported to the Acorn if I > >want to play it without having to travel to Coventry to get to a Sparc > >Station. > > Well - just install RiscBSD and play it on that - the beta version > apparently is pretty stable now and runs Xpilot, albeit slowly without > any FP hardware. I'm waiting for that StrongARM processor before I > attempt to play Xpilot on my machine at home ... ;-) > > Cheers, > Nexus 6 > aka Toby Haynes > -- > Toby Haynes | "I COULD MURDER A CURRY" - Death > Somewhere in Cambridge | Mort by Terry Pratchett From: tjwh1@mrao.cam.ac.uk (Toby Haynes) Subject: Re: Reply to juggler re: LaserQuest Date: 1996/08/13 Message-ID: <4uphkp$18n@lyra.csx.cam.ac.uk>#1/1 references: <4tk7su$gg0@client2.news.psi.net> <19960803.031558.09@aschamhs.demon.co.uk> <4ukn69$8lp@lyra.csx.cam.ac.uk> <19960812.181323.45@aschamhs.demon.co.uk> newsgroups: rec.games.computer.xpilot,rec.games.corewar,rec.games.design,rec.games.diplomacy In article <19960812.181323.45@aschamhs.demon.co.uk>, John Wright wrote: >"Karen M. Gould": >> Yes, I have been to LaserQuest with a Professor at Welcome CRC and his two >> sons, >> 7 and 9 at the time, as well as all their friends who attended their birthday >> party, and a few o ther supervising adults. It was a blast (heheh > Ah yes. Little kids. Muhahahaha! >;) [snip] > May have to arrange something. Urm... I hate arranging things. Well - if you are going to have a Xpilot Laserquest session in Cambridge, count me in! > Darn. I'm having to wait until Xpilot gets ported to the Acorn if I >want to play it without having to travel to Coventry to get to a Sparc >Station. Well - just install RiscBSD and play it on that - the beta version apparently is pretty stable now and runs Xpilot, albeit slowly without any FP hardware. I'm waiting for that StrongARM processor before I attempt to play Xpilot on my machine at home ... ;-) Cheers, Nexus 6 aka Toby Haynes -- Toby Haynes | "I COULD MURDER A CURRY" - Death Somewhere in Cambridge | Mort by Terry Pratchett From: karl.castle@Ace.net.au Subject: RedCode Date: 1996/08/13 Message-ID: #1/1 newsgroups: rec.games.corewar ;redcode-b ;name Pit-Scanner v1.2 ;author Karl Castle ;assert 1 PIT JMP PIT AD ADD #8, SCAN ;I'm a _beginner_, but I'm writing this. ;the warrior jmp-bombs enemy processes, ;stopping them in their tracks. ;What do I do to switch execution to SC2 ? SCAN JMZ AD, 13 ATTACK MOV PIT, @SCAN JMP AD BOMB DAT #0, #0 S2 ADD #4, SC2 SC2 JMZ S2, -2 ATT MOV BOMB, @SCAN JMP S2 END AD If you can help, thankyou. Karl Castle, karl.castle@ace.net.au From: Beppe Bezzi Subject: Re: more about pizza test option Date: 1996/08/14 Message-ID: #1/1 newsgroups: rec.games.corewar Myer R. Bremer wrote: >In article <13199612.Amiga@sci.fi>, Ilmari Karonen wrote: >>Well, I just noticed that I get messages from tests even though my >>noise level is standard. IMHO tests should only be shown to those who >>have set 'verbose' on. This is the first test I've seen so far, but if >>it becomes more common this could become a problem. What do other >>people think about it? >> >>-- >>Ilmari Karonen >> > >greetings. > >i second that. all ;test challenges should only go to verbose modes. I disagree. One should receive results from test that would have made the hill, as I think it's now. Perhaps Thos could add another option, something like ;redcode-94 notest for those wishing to get sucessful chalenges and no tests >not to put any pressure on thos, but where's that ;fight option to >challenge one warrior only (or groups of warriors)? i hope that >will eventually get implemented. > Before the fight option I'd like to see implemented the ;newredcode to change redcode attribute from verbose to quiet for example; I'm near to go away in vacation and I'm sure that the hill will soon go back to one hundred challenges per week. >sidelight: when i go to post a message with my newsreader, i get this >dire warning that it will cost thousands of dollars, etc etc . . . ... It's not a big problem. You can answer one of the 'make money fast' postings and repay the damage. :-) >thank you. > >m r bremer > -Beppe From: Anders Ivner Subject: Re: more about pizza test option Date: 1996/08/14 Message-ID: <9608140822.AA01347@su4-6.ida.liu.se>#1/1 newsgroups: rec.games.corewar > In article <13199612.Amiga@sci.fi>, Ilmari Karonen wrote: > >Well, I just noticed that I get messages from tests even though my > >noise level is standard. IMHO tests should only be shown to those who > >have set 'verbose' on. This is the first test I've seen so far, but if > >it becomes more common this could become a problem. What do other > >people think about it? > > > >-- > >Ilmari Karonen > > > > greetings. > > i second that. all ;test challenges should only go to verbose modes. > > m r bremer I disagree. All test challenges that would've made the hill should be mailed (as it is now). This should be the same amount of mail as we've gotten used to. Besides, it's interesting to see what others are experimenting with at the moment. Maybe we need more options (such as tests/notests). /Anders From: jklewis@ren.us.itd.umich.edu (John K. Lewis) Subject: Re: Artificial Life, Redcode, & Tierra (was Re: Rock, Paper, Scissors) Date: 1996/08/14 Message-ID: <4utahp$t28@lastactionhero.rs.itd.umich.edu>#1/1 references: <960814063739_102741.2022_GHT61-4@CompuServe.COM> newsgroups: rec.games.corewar Ross Morgan-Linial (rmorganl@fhcrc.org) wrote: : Say, has anyone out there done any newish work on evolving warriors? I've : been thinking about trying, but I don't know much about GAs... I've been doing a lot of work in this area. It's the main reason I haven't been writting more warriors. I want to finish more work on the process before I write about results but I did have a warrior evolve that beat Twill. John - [ john k. lewis ] [ jklewis@umich.edu ] [ 7-3748 ] [ sig.virus v1.4 ] From: Ross Morgan-Linial Subject: Artificial Life, Redcode, & Tierra (was Re: Rock, Paper, Scissors) Date: 1996/08/14 Message-ID: #1/1 references: <960814063739_102741.2022_GHT61-4@CompuServe.COM> newsgroups: rec.games.corewar On 14 Aug 1996, Justin Kao wrote: // >Me! Meee! I got into it because of a book called 'Artificial Life' (great // >book) - it mentions Corewar as a precursor of several artifical life // >systems. // // I read that too! Weird. :-) You can find Tierra online too, except // there's only source code. I downloaded it but haven't compiled it yet. I compiled it, and ran it. It's neat, but the instruction set is more complex than Redcode. It's fun watching, though... Say, has anyone out there done any newish work on evolving warriors? I've been thinking about trying, but I don't know much about GAs... ------ Ross Morgan-Linial * rmorganl@fhcrc.org It's easier to do a stupid thing stupidly than an intelligent thing intelligently. From: jbui@scd.hp.com (Joseph Bui) Subject: Re: RedCode Date: 1996/08/14 Message-ID: <4usrar$3vn@hpscit.sc.hp.com>#1/1 references: newsgroups: rec.games.corewar karl.castle@Ace.net.au wrote: > ;redcode-b > ;name Pit-Scanner v1.2 > ;author Karl Castle > ;assert 1 > PIT JMP PIT > AD ADD #8, SCAN > SCAN JMZ AD, 13 > ATTACK MOV PIT, @SCAN ; replaced JMP AD with: SPL AD ; moved BOMB DAT #0, #0 elsewhere > S2 ADD #4, SC2 > SC2 JMZ S2, -2 > ATT MOV BOMB, @SCAN ; removed JMP S2 so that split process will die > BOMB DAT #0, #0 > END AD > ;I'm a _beginner_, but I'm writing this. > ;the warrior jmp-bombs enemy processes, > ;stopping them in their tracks. > ;What do I do to switch execution to SC2 ? I'm also a beginner, but I'll try and answer this. It looks like you wanted to scan for non-0 B fields, then throw a JMP 0 into that enemy program. In addition, you want to DAT bomb the enemy process. Personally, I would put the following after SPL AD: ADD SCAN, TARGET MOV #16, COUNTER KILL MOV BOMB, Subject: Re: Rock, Paper, Scissors Date: 1996/08/14 Message-ID: <960814063739_102741.2022_GHT61-4@CompuServe.COM>#1/1 newsgroups: rec.games.corewar >Me! Meee! I got into it because of a book called 'Artificial Life' (great >book) - it mentions Corewar as a precursor of several artifical life >systems. I read that too! Weird. :-) You can find Tierra online too, except there's only source code. I downloaded it but haven't compiled it yet. Justin From: sd@ecst.csuchico.edu (Alfalfa Male) Subject: Pizza Hills closed AGAIN?! Date: 1996/08/15 Message-ID: <4v0242$7a3@charnel.ecst.csuchico.edu>#1/1 newsgroups: rec.games.corewar Sorry, but it looks like the pizza hills will be down for the weekend once again. Apparently they're having a lot of problems trying to do some upgrades while the system is up, so they're going to shut it down from Friday the 16th at 1200 PDT to Sunday 1800 PDT. I apologize for the short notice, but I'm almost positive this is the last shutdown at least for a while. Thos -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~\/~~\ /~~~\/\ / \ \ / /~\ /~~~~~YY~~~\\ /~~ Thomas "Thos" Davies V \/\ /\ V / V |\/\/| V\ / sd@ecst.csuchico.edu V \ / | / | V Internet Pizza Server \/ | /\ | Member C.W.M. Corewar King of the Hill information |/oo\| CAVE ON Since 1987 http://www.ecst.csuchico.edu/~pizza/koth/ |/\| From: sd@ecst.csuchico.edu (Alfalfa Male) Subject: Re: more about pizza test option Date: 1996/08/15 Message-ID: <4v01pg$79r@charnel.ecst.csuchico.edu>#1/1 references: <13199612.Amiga@sci.fi> newsgroups: rec.games.corewar In article <13199612.Amiga@sci.fi>, Ilmari Karonen wrote: >Well, I just noticed that I get messages from tests even though my >noise level is standard. IMHO tests should only be shown to those who >have set 'verbose' on. This is the first test I've seen so far, but if >it becomes more common this could become a problem. What do other >people think about it? Right now tests act just like a non-test. If it's successful, it sends to all but quiet, if it's unsuccessful, it sends to none but verbose. Thos -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~\/~~\ /~~~\/\ / \ \ / /~\ /~~~~~YY~~~\\ /~~ Thomas "Thos" Davies V \/\ /\ V / V |\/\/| V\ / sd@ecst.csuchico.edu V \ / | / | V Internet Pizza Server \/ | /\ | Member C.W.M. Corewar King of the Hill information |/oo\| CAVE ON Since 1987 http://www.ecst.csuchico.edu/~pizza/koth/ |/\| From: Tim Chapman Subject: Re: Artificial Life, Redcode, & Tierra Date: 1996/08/15 Message-ID: #1/1 newsgroups: rec.games.corewar On Thu, 15 Aug 1996, Erwin Hugo Achermann wrote: > > Maybe you would give us the pointer to Tierra, what is it? I have > never heard of it. > Some links to Tierra sites can be found on: http://homepage.seas.upenn.edu/%7Eale/cplxsys.html > > The big question: how to represent a warrior, in such a way that > automated mutation and crossover have a better chance to produce viable > offsprings? Genetic warriors apparently do better in environments (like Tierra, I think) which are subject to occasional random modification to core, that would often damage a human designed warrior. The GA tends to evolve warriors very robust to small changes. Another idea is to design warriors with many useless instructions (like NOP) to pad out the code and therefore make small changes to values (eg. in JMP instructions) less likely to be fatal to the warrior. These type of warriors will be very inefficient against human designed opponents however. I am interested to see what John K Lewis has done... Tim Chapman From: jwilkinson@mail.utexas.edu Subject: Re: Artificial Life, Redcode, & Tierra Date: 1996/08/15 Message-ID: <199608152223.RAA25841@mail.utexas.edu>#1/1 newsgroups: rec.games.corewar >> The big question: how to represent a warrior, in such a way that >> automated mutation and crossover have a better chance to produce viable >> offsprings? > >Genetic warriors apparently do better in environments (like Tierra, I >think) which are subject to occasional random modification to core, >that would often damage a human designed warrior. The GA tends to evolve >warriors very robust to small changes. > >Another idea is to design warriors with many useless instructions (like >NOP) to pad out the code and therefore make small changes to values (eg. >in JMP instructions) less likely to be fatal to the warrior. These type of >warriors will be very inefficient against human designed opponents however. I made that proposal the last time GAs were brought up. The thing is, however, that if you start of with say a warrior of 100 nops (which seems a good place to begin) warriors will eventually develop the JMP 0 change, which will allow one warrior to not commit suicide while the other one does. The next step would be a warrior with some type of bombing. The bombing loop would probably be terribly inneficient to begin with. However, after time, the removal of the NOPs in the middle of the loop would clear things up... From: Erwin Hugo Achermann Subject: Re: Artificial Life, Redcode, & Tierra Date: 1996/08/15 Message-ID: <199608150927.LAA15749@ru10.inf.ethz.ch>#1/1 newsgroups: rec.games.corewar On 15 Aug 1996, Ross Morgan-Linial writes: > // I read that too! Weird. :-) You can find Tierra online too, except > // there's only source code. I downloaded it but haven't compiled it yet. > > I compiled it, and ran it. It's neat, but the instruction set is more > complex than Redcode. It's fun watching, though... > Maybe you would give us the pointer to Tierra, what is it? I have never heard of it. > Say, has anyone out there done any newish work on evolving warriors? I've > been thinking about trying, but I don't know much about GAs... > Well yes, maybe you realized Adelmo on the beginners hill. It is one of my best warrior evolved so far, but to be honest it is the least damaged version of P.Kline's Yogi-Bear. Up to now, i didn't manage to simulate something that deserves the name 'evolved warrior'. Let me explain why this is: Genetic algorithms (GA) work according to Darwin's "survival of the fittest". The better an individual in a finite population scores, the more likely it breeds with another successful individual. That's the way Evolution separates good guys from bad guys. But how do better and even better guys evolve? In nature (and in GAs) there is a Mutation and a Crossover. The former changes small information units in a representation of an individual, the latter intermingles the representation of the two breeding individuals. Hopefully these 'genetic operators' will from time to time produce successful individuals. (I hope i didn't mix it up too much.) I decided to make such an evolution in the arena of core wars. But the big question is: How should i represent a warrior? If your mutations and crossover work on the Redcode directly (eg change a modifier, change a mov into a spl, cut two warriors into pieces and shuffle etc.) A successful mutation/crossover is !!very~very! unlikely. But on the other hand, it's exactly how you Redcoders design a new warrior, you take a silk module, take a bomber, stick them together (which seems to me the hardest part), tune the constants, and storm the hill :-) The big question: how to represent a warrior, in such a way that automated mutation and crossover have a better chance to produce viable offsprings? If you have any ideas, questions or proposals about how to represent a warrior, how to determine its fitness, or about how a better mutation/crossover might look like, i would be glad if you shared them with me. Erwin Achermann -- Erwin Achermann Tel: ++41 1 632 74 40 Institut fuer wissenschaftliches Rechnen FAX: ++41 1 632 11 72 ETH Zentrum, IFW C29.2 email: achermann@inf.ethz.ch CH-8092 Zuerich URL: http://www.inf.ethz.ch/personal/acherman/ > Perfection is reached, not when there is no longer anything to add, < > but when there is no longer anything to take away. < > -- Antoine de Saint-Exupery < From: Tim Chapman Subject: Re: Artificial Life, Redcode, & Tierra Date: 1996/08/16 Message-ID: #1/1 newsgroups: rec.games.corewar On Fri, 16 Aug 1996, Loh Weng Keong Calvin wrote: > If you can really modularize a warrior's components, then you can just > mix and match these modules. For example, a bomber has mainly 2 parts, > i.e. the body and its constants. In fact, almost every warrior has > certain constants which can be modified without killing it. All these > constants affect would be the survival rate and kill rate of a > warrior. Also, each warrior type has many different implementations, > e.g. an imp : we have 3-pointers, 7-pointers, etc; we also have > continuous-launching imps and mirrored imps as well as djn-launchers > and jmp-add launchers. > > I envision 2 parts to a mutation : mutate the constants, or mutate > the paper/stone/scanner/imp modules. > The problem with this approach is that you are only using the GA to optimise existing warriors. You aren't ever going to evolve a fundamentally different piece of code, like a new type of attack. Tim Chapman From: jklewis@ren.us.itd.umich.edu (John K. Lewis) Subject: Re: Newbie Date: 1996/08/16 Message-ID: <4v20gj$2l4@lastactionhero.rs.itd.umich.edu>#1/1 references: <32140D98.41C6@kirke.zcu.cz> newsgroups: rec.games.corewar Petr Ledvina (ledvinap@kirke.zcu.cz) wrote: : Where can one get something about corewars? http://www.ecst.csuchico.edu/~pizza/koth/ [ john k. lewis ] [ jklewis@umich.edu ] [ 7-3748 ] [ sig.virus v1.4 ] From: Tim Chapman Subject: Re: Artificial Life, Redcode, & Tierra Date: 1996/08/16 Message-ID: #1/1 newsgroups: rec.games.corewar On Thu, 15 Aug 1996 jwilkinson@mail.utexas.edu wrote: > >Another idea is to design warriors with many useless instructions (like > >NOP) to pad out the code and therefore make small changes to values (eg. > >in JMP instructions) less likely to be fatal to the warrior.These type of > >warriors will be very inefficient against human designed opponents however. > I made that proposal the last time GAs were brought up. The thing is, however, > that if you start of with say a warrior of 100 nops (which seems a good place > to begin) warriors will eventually develop the JMP 0 change, which will allow > one warrior to not commit suicide while the other one does. The next step > would be a warrior with some type of bombing. The bombing loop would probably > be terribly inneficient to begin with. However, after time, the removal of > the NOPs in the middle of the loop would clear things up... In real genetics there is an incredible amount of latency. Genetic patterns can build up over time without actually being active until a control gene is set. Genetic code can form small units, which can build upon themselves to develop an advanced system. In genetic corewar this is not possible as any latent changes in the warrior will crucially affect it. Maybe better genetics could be simulated by encoding warriors at a deeper level, where the genetic code is not directly related to the warrior code, but rather codes for an algorithm to generate the warrior. The warrior gene could be designed so as to allow sub-units of code to build up in the gene, but which would not necessarily be present in the warrior unless a particular control gene was active. This might give a way for more advanced warriors to be evolved. Tim Chapman From: Petr Ledvina Subject: Newbie Date: 1996/08/16 Message-ID: <32140D98.41C6@kirke.zcu.cz>#1/1 newsgroups: rec.games.corewar Where can one get something about corewars? Petr Ledvina ledvinap@kirke.zcu.cz From: jklewis@ren.us.itd.umich.edu (John K. Lewis) Subject: Re: Artificial Life, Redcode, & Tierra Date: 1996/08/16 Message-ID: <4v20es$2l4@lastactionhero.rs.itd.umich.edu>#1/1 references: newsgroups: rec.games.corewar Loh Weng Keong Calvin (lohwengk@iscs.nus.sg) wrote: : I envision 2 parts to a mutation : mutate the constants, or mutate : the paper/stone/scanner/imp modules. I've been working under the assumption that there are strategies that have been overlooked by humans and which are much more likely to be found by a computer using GA. Because of this assumption, I have chosen not to use a modular evolutionary system. I may find, however, that this was an error and try a modular system after all. [ john k. lewis ] [ jklewis@umich.edu ] [ 7-3748 ] [ sig.virus v1.4 ] From: jklewis@ren.us.itd.umich.edu (John K. Lewis) Subject: Re: Artificial Life, Redcode, & Tierra Date: 1996/08/16 Message-ID: <4v2093$2l4@lastactionhero.rs.itd.umich.edu>#1/1 references: <199608152223.RAA25841@mail.utexas.edu> newsgroups: rec.games.corewar jwilkinson@mail.utexas.edu wrote: : I made that proposal the last time GAs were brought up. The thing is, however, : that if you start of with say a warrior of 100 nops (which seems a good place : to begin) warriors will eventually develop the JMP 0 change, which will allow : one warrior to not commit suicide while the other one does. The next step : would be a warrior with some type of bombing. The bombing loop would probably : be terribly inneficient to begin with. However, after time, the removal of : the NOPs in the middle of the loop would clear things up... Actually the next step was a decremental core-clear. This is the program which beat twill. While I started with a set of random code for each program, the real problem was getting the code to continue to evolve past the jmp 0 or spl 0 stage. I am currently upgrading the code to do this. John K. Lewis From: Loh Weng Keong Calvin Subject: Re: Artificial Life, Redcode, & Tierra Date: 1996/08/16 Message-ID: #1/1 newsgroups: rec.games.corewar On Thu, 15 Aug 1996, Erwin Hugo Achermann wrote: > I decided to make such an evolution in the arena of core wars. But the > big question is: How should i represent a warrior? If your mutations > and crossover work on the Redcode directly (eg change a modifier, > change a mov into a spl, cut two warriors into pieces and shuffle > etc.) A successful mutation/crossover is !!very~very! unlikely. But on > the other hand, it's exactly how you Redcoders design a new warrior, > you take a silk module, take a bomber, stick them together (which seems > to me the hardest part), tune the constants, and storm the hill :-) > > The big question: how to represent a warrior, in such a way that > automated mutation and crossover have a better chance to produce viable > offsprings? If you can really modularize a warrior's components, then you can just mix and match these modules. For example, a bomber has mainly 2 parts, i.e. the body and its constants. In fact, almost every warrior has certain constants which can be modified without killing it. All these constants affect would be the survival rate and kill rate of a warrior. Also, each warrior type has many different implementations, e.g. an imp : we have 3-pointers, 7-pointers, etc; we also have continuous-launching imps and mirrored imps as well as djn-launchers and jmp-add launchers. I envision 2 parts to a mutation : mutate the constants, or mutate the paper/stone/scanner/imp modules. Calvin Loh From: juggler@aschamhs.demon.co.uk (John Wright) Subject: Re: Reply to juggler re: LaserQuest Date: 1996/08/17 Message-ID: <19960817.022154.87@aschamhs.demon.co.uk>#1/1 references: <4ukn69$8lp@lyra.csx.cam.ac.uk> <19960812.181323.45@aschamhs.demon.co.uk> <4uphkp$18n@lyra.csx.cam.ac.uk> newsgroups: rec.games.computer.xpilot,rec.games.corewar,rec.games.design Jamie Dreier: > Could we get rec.games.diplomacy out of the distribution list for this > thread, please? Thanks. Wasn't me. :) BFN, Juggler. -- Juggler (dza.gler). late OE. 2. A magician, wizard, sorcerer; a performer of legerdemain; a conjurer OE. 3. transf. and fig. One who deceives by trickery ME. From: hagbard@dcs.warwick.ac.uk (David Beaumont) Subject: Re: Reply to juggler re: LaserQuest Date: 1996/08/17 Message-ID: <1996Aug17.160335.24629@dcs.warwick.ac.uk>#1/1 references: <4tk7su$gg0@client2.news.psi.net> <19960803.031558.09@aschamhs.demon.co.uk> <4ukn69$8lp@lyra.csx.cam.ac.uk> <19960812.181323.45@aschamhs.demon.co.uk> <4uphkp$18n@lyra.csx.cam.ac.uk> newsgroups: rec.games.computer.xpilot,rec.games.corewar,rec.games.design pl436000@brownvm.brown.edu (Jamie Dreier) writes: >Could we get rec.games.diplomacy out of the distribution list for this >thread, please? Thanks. Could we avoid having people reply to posts by including the whole of the previous article just so they can add 16 words at the top ? >> Well - just install RiscBSD and play it on that - the beta version >> apparently is pretty stable now and runs Xpilot, albeit slowly without >> any FP hardware. I'm waiting for that StrongARM processor before I >> attempt to play Xpilot on my machine at home ... ;-) Urm, the StrongARM doesn't have an FPU as far as I know. Cheers, David. From: juggler@aschamhs.demon.co.uk (John Wright) Subject: Re: Reply to juggler re: LaserQuest Date: 1996/08/17 Message-ID: <19960817.021543.49@aschamhs.demon.co.uk>#1/1 references: <19960803.031558.09@aschamhs.demon.co.uk> <4ukn69$8lp@lyra.csx.cam.ac.uk> <19960812.181323.45@aschamhs.demon.co.uk> <4uphkp$18n@lyra.csx.cam.ac.uk> newsgroups: rec.games.computer.xpilot,rec.games.corewar,rec.games.design,rec.games.diplomacy Toby Haynes: > Well - just install RiscBSD and play it on that - the beta version > apparently is pretty stable now and runs Xpilot, albeit slowly without > any FP hardware. I'm waiting for that StrongARM processor before I > attempt to play Xpilot on my machine at home ... ;-) But you've *got* to get another harddisc to run it on and I've no money even thought I'd love to have another and a faster cdrom drive or maybe... the list goes on and on. Anyhow, might be fun porting Xpilot. :) And I think I'm the only person who's actually scared of the StrongARM processor. :) BFN, Juggler. -- Juggler (dza.gler). late OE. 2. A magician, wizard, sorcerer; a performer of legerdemain; a conjurer OE. 3. transf. and fig. One who deceives by trickery ME. From: jklewis@ren.us.itd.umich.edu (John K. Lewis) Subject: Re: Artificial Life, Redcode, & Tierra Date: 1996/08/17 Message-ID: <4v5a5m$5ml@lastactionhero.rs.itd.umich.edu>#1/1 references: newsgroups: rec.games.corewar Tim Chapman (lpyktpc@psyc.nott.ac.uk) wrote: : In real genetics there is an incredible amount of latency. Genetic : patterns can build up over time without actually being active until a : control gene is set. Genetic code can form small units, which can build : upon themselves to develop an advanced system. In genetic corewar this is : not possible as any latent changes in the warrior will crucially affect : it. I disagree. What you have described is very similar to what if happening in the randomly generated code I am working with. The code might carry in it some subroutine which is skipped for generations. After a specific mutation or crossover, that code is used (revealed?) and the basic strategy of the warrior changes. : Maybe better genetics could be simulated by encoding warriors at a deeper : level, where the genetic code is not directly related to the warrior code, : but rather codes for an algorithm to generate the warrior. The warrior : gene could be designed so as to allow sub-units of code to build up in : the gene, but which would not necessarily be present in the warrior unless : a particular control gene was active. This might give a way for more : advanced warriors to be evolved. One idea I was working with was creating "strategies" as genes. An example would be a bomber; Pointer,Bomb,Index,Loopback These are all required for produce a bomber, like this example: loopback mov.i bomb,@pointer add.b index,pointer jmp loopback bomb dat 0,0 pointer dat 0,0 index dat 10,10 Humans see this and say "hey, I can optimize this!" While the computer might do just crazy things like combine the bomb and the index, or make the pointer, index and bomb one thing. More interesting would be mixing two types of warriors/strategies. What if you mixed the bomber and the paper. Any, the point here is that to do this you need to thing up lots of strategies and thier basic needs (pointer,bomb...etc.). While I think this might produce very interesting designs, I want to find strategies overlooked by humans first. This will probably by the next stage I go to after looking ofr GA originated strategies. John- [ john k. lewis ] [ jklewis@umich.edu ] [ 7-3748 ] [ sig.virus v1.4 ] From: Ross Morgan-Linial Subject: Re: more about pizza test option Date: 1996/08/18 Message-ID: #1/1 references: <13199612.Amiga@sci.fi> <4v01pg$79r@charnel.ecst.csuchico.edu> newsgroups: rec.games.corewar On 15 Aug 1996, Alfalfa Male wrote: // In article <13199612.Amiga@sci.fi>, Ilmari Karonen wrote: // >Well, I just noticed that I get messages from tests even though my // >noise level is standard. IMHO tests should only be shown to those who // >have set 'verbose' on. This is the first test I've seen so far, but if // >it becomes more common this could become a problem. What do other // >people think about it? // // Right now tests act just like a non-test. If it's successful, it sends to // all but quiet, if it's unsuccessful, it sends to none but verbose. // // Thos Well, since I don't normally want to know how good a test is, only when a new program gets on the hill, I think tests should go only to 'verbose'. I think the options should be: Verbose - You are told of all challenges, interesting or not. Normal - You are only told of interesting challenges (changes in the hill) Quiet - You are told nothing. Since the test option encourages people to send in programs many times, even when they would make the hill, I don't want to suddenly start recieving large amounts of mail :-) ------ Ross Morgan-Linial * rmorganl@fhcrc.org It's easier to do a stupid thing stupidly than an intelligent thing intelligently. From: hal.barber@gshbbs.com (HAL BARBER) Subject: Video games for sale Date: 1996/08/18 Message-ID: <8C6A0F8.013D000691.uuout@gshbbs.com>#1/1 newsgroups: rec.games.corewar I have the following games for sale: Sega CD: Prize Fighters $ 5 Sonic CD $ 7 Sega Genesis: Jeopardy $ 20 Risk $ 30 Toughman Contest $ 25 Wheel of Fortune $ 20 Super NES: Hammer Lock $ 25 RapJam $ 25 Relief Pitcher $ 20 Sky Blazer $ 23 3 DO: FIFA Soccer $ 5 Panzer General $ 20 Perfect General $ 25 Perfect General $ 25 Shadow $ 15 Shockwave $ 5 Shockwave: Operation Jump $ 15 Space Pirates $ 15 Space Shuttle $ 7 Super Street Fighter 2 Turbo $ 20 Syndicate $ 15 Theme Park $ 12 Please add $2.00 for shipping. I am a private owner, but I will give a 30-day money back guarantee for all defective games. Ways to contact me: Phone: (804) 595-9318 -or- (800) 484-1495, sec code 6245 e-mail: hbarber@visi.net ... messages. --- Blue Wave/QWK v2.10 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= The GSH BBS (804)420-0475 Internet: @gshbbs.com Fido (1:275/153) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From: Tim Chapman Subject: Re: Artificial Redcode, resume Date: 1996/08/19 Message-ID: #1/1 newsgroups: rec.games.corewar On Mon, 19 Aug 1996, Erwin Hugo Achermann wrote: > It's great that thread comes up. I would like to collect some thoughts > that were expressed in this discussion so far and to push that > discussion maybe one round further. Good idea. > > The GA tends to evolve warriors very robust to small changes. > This is correct provided that the GA works on human-readable redcode > directly. Yep. And as you say later, its the biggest problem... > Is there an archive where these old GA Discussions are available? > This removal of superfluous NOPs isn't to be expected but after a very > long time of computing. I think there was... it should be available from the corewar ftp sites. > > > > If you can really modularize a warrior's components, then you can > > > just mix and match these modules. [stuff deleted] I envision 2 parts > > > to a mutation : mutate the constants, or mutate the > > > paper/stone/scanner/imp modules. > > > > The problem with this approach is that you are only using the GA to > > optimise existing warriors. You aren't ever going to evolve a > > fundamentally different piece of code, like a new type of attack. > I agree partly. But the GA might very easily find some > combinations of known modules that no human thought of and that > nonetheless are quite successful. Right, but like John K. Lewis I'm more interested in using GAs to find original strategies, not just successful recombinations of old ones. I don't see any reason why modular evolution shouldn't work though, if thats what people want to do. > > > Maybe better genetics could be simulated by encoding warriors at a > > deeper level, where the genetic code is not directly related to the > > warrior code, but rather codes for an algorithm to generate the > > warrior. > In my opinion this is the way to go: Consider the biological "set of > instructions"...[good argument]... > .....A new working piece of code has no neighborhood (in the redcode > space) that is half as good. It's either working or it's worth nothing > more than any other piece of random code. We have to melt these > needles out of that big haystack by introducing a genetic code that > is translated by an algorithm and thus produces viable redcode. > Yes. So how do we go about this? Perhaps it would be possible to design a warrior as a hierarchy. At the lowest level there would be the actual instructions themselves, but then the structure of the tree would allow groups of instructions to be formed as segments. These segments could then be further combined and so on. The structure would also need 'control genes' which describe which branches of the hierarchy to use in the finished warrior. Genetic mutations could be at an instruction level, changing the links in the hierachy, adding or removing control genes, and even complete cut and pasting of hierachy sections between warriors. As well as this, perhaps using labels instead of actual values would help to reduce the size of the instruction set? Tim Chapman From: Tim Chapman Subject: Re: Artificial Life, Redcode, & Tierra Date: 1996/08/19 Message-ID: #1/1 newsgroups: rec.games.corewar On Sat, 17 Aug 1996, John K. Lewis wrote: > Tim Chapman (lpyktpc@psyc.nott.ac.uk) wrote: > : In real genetics there is an incredible amount of latency. Genetic > : patterns can build up over time without actually being active until a > : control gene is set. Genetic code can form small units, which can build > : upon themselves to develop an advanced system. In genetic corewar this is > : not possible as any latent changes in the warrior will crucially affect > : it. > > I disagree. What you have described is very similar to what if happening > in the randomly generated code I am working with. The code might carry in > it some subroutine which is skipped for generations. After a specific > mutation or crossover, that code is used (revealed?) and the basic > strategy of the warrior changes. The difference is that by needing to store the latent strategy lines in the warrior code itself, the warrior will soon become very large and inefficient. If these are stored in an algorithm they can still be useful without damaging the loaded warrior code any. This probably doesn't matter too much for evolved warriors vs. evolved warriors, but for more serious battles it could become a problem. > > One idea I was working with was creating "strategies" as genes. An > example would be a bomber; > > Pointer,Bomb,Index,Loopback > > [......] > > Any, the point here is that to do this you need to thing up lots of > strategies and thier basic needs (pointer,bomb...etc.). While I think > this might produce very interesting designs, I want to find strategies > overlooked by humans first. This will probably by the next stage I go to > after looking ofr GA originated strategies. I agree that it would be nice to discover new strategies using GAs. I also quite like the idea of encoding strategies in the genes. If these 'strategies' are kept as simple as possible (perhaps only 1-2 lines each) then this approach could still work to discover new programs. Tim Chapman From: jwilkinson@mail.utexas.edu Subject: Re: Artificial Life, Redcode, & Tierra Date: 1996/08/19 Message-ID: <199608191520.KAA22879@mail.utexas.edu>#1/1 newsgroups: rec.games.corewar lpyktpc@psyc.nott.ac.uk wrote: >> I disagree. What you have described is very similar to what if happening >> in the randomly generated code I am working with. The code might carry in >> it some subroutine which is skipped for generations. After a specific >> mutation or crossover, that code is used (revealed?) and the basic >> strategy of the warrior changes. > >The difference is that by needing to store the latent strategy lines in >the warrior code itself, the warrior will soon become very large and >inefficient. If these are stored in an algorithm they can still be >useful without damaging the loaded warrior code any. This probably >doesn't matter too much for evolved warriors vs. evolved warriors, but >for more serious battles it could become a problem. You could say the same thing about REAL organisms. If scientists sat around all day mulling over the code for an amoeba, they could probably build a better one (and I'm sure we will someday), but the point is not to try to get a GA to create the type of warrior humans make. I suppose either of the two methods would produce interesting, though dramatically different results... From: jbui@scd.hp.com (Joseph Bui) Subject: Name that warrior Date: 1996/08/19 Message-ID: <4va9sf$9c4@hpscit.sc.hp.com>#1/1 newsgroups: rec.games.corewar I've read FAQs and tutorials, but, when people describe their code, I'm sometimes unsure of what each tactic means. Is this list accurate? Bomb - Move DAT to "random" places in core (see below) Linear fwd, bkwd. Binary (??). Core clear - Move DAT to every place in core Linear fwd, bkwd (Bomb by 1). Scan - Look thru core for non-zero values Linear fwd, bkwd. Binary. Quick (??). Stun - Bomb, but with JMP 0 or SPL 0 ??? - Execute opponent's code Paper - SPL a lot (defensive) Vampire - ??? ??? - Modify values (not instructions) in core to hamper opponent Imp - Copy code to new location and execute launcher - stays put, SPLs imps spiral - many imps working together Gate - Bomb an area of core continuously (defensive) imp gate - just bomb one location ??? - more complex, but still stationary bombing pattern ??? - Error correcting code (defensive)* * This is what I've been working on thru (1) checksums to defeat opponents throwing random A or B field values and (2) having redundant copies of code that check each other. I'm working on both syncronous and async redundant code checking. I guess I'm really looking for a glossary. Thanks, Joe Bui From: Ross Morgan-Linial Subject: Re: Name that warrior Date: 1996/08/19 Message-ID: #1/1 references: <4va9sf$9c4@hpscit.sc.hp.com> newsgroups: rec.games.corewar On 19 Aug 1996, Joseph Bui wrote: // I've read FAQs and tutorials, but, when people describe their code, I'm // sometimes unsure of what each tactic means. Is this list accurate? // // Bomb - Move DAT to "random" places in core (see below) // Linear fwd, bkwd. Binary (??). Not neccessarily DAT. Anything qualifies as bombing, except possible JMP // // Core clear - Move DAT to every place in core // Linear fwd, bkwd (Bomb by 1). Not always DAT, again. // // Scan - Look thru core for non-zero values // Linear fwd, bkwd. Binary. Quick (??). Not neccessarily non-zero - there are other ways of testing. // // Stun - Bomb, but with JMP 0 or SPL 0 Any way of slowing opponent down, not necessarily bombing. // // ??? - Execute opponent's code This is pretty rare. // // Paper - SPL a lot (defensive) No, other things split a lot. Create copies of self. // // Vampire - ??? Bomb with JMPs pointing to a special section of code ('pit') // // ??? - Modify values (not instructions) in core to hamper opponent Stunning. // // Imp - Copy code to new location and execute // launcher - stays put, SPLs imps // spiral - many imps working together No. Any mobile program/part consisting only of MOVs. // // Gate - Bomb an area of core continuously (defensive) // imp gate - just bomb one location // ??? - more complex, but still stationary bombing pattern Imp gate (aka Gate) - repeatedly modify a single instruction // // ??? - Error correcting code (defensive)* Very slow. // // * This is what I've been working on thru (1) checksums to defeat opponents // throwing random A or B field values and (2) having redundant copies of code // that check each other. I'm working on both syncronous and async redundant // code checking. // // I guess I'm really looking for a glossary. // Thanks, // Joe Bui // // ------ Ross Morgan-Linial * rmorganl@fhcrc.org It's easier to do a stupid thing stupidly than an intelligent thing intelligently. From: David A Johnston Subject: Re: Artificial Life, Redcode, & Tierra Date: 1996/08/19 Message-ID: <3218EE6C.446B9B3D@pogo.wv.tek.com>#1/1 references: <4v5a5m$5ml@lastactionhero.rs.itd.umich.edu> newsgroups: rec.games.corewar John K. Lewis wrote: > > Tim Chapman (lpyktpc@psyc.nott.ac.uk) wrote: > : In real genetics there is an incredible amount of latency. Genetic > : patterns can build up over time without actually being active until a > : control gene is set. Genetic code can form small units, which can build > : upon themselves to develop an advanced system. In genetic corewar this is > : not possible as any latent changes in the warrior will crucially affect > : it. > > I disagree. What you have described is very similar to what if happening > in the randomly generated code I am working with. The code might carry in > it some subroutine which is skipped for generations. After a specific > mutation or crossover, that code is used (revealed?) and the basic > strategy of the warrior changes. > > : Maybe better genetics could be simulated by encoding warriors at a deeper > : level, where the genetic code is not directly related to the warrior code, > : but rather codes for an algorithm to generate the warrior. The warrior > : gene could be designed so as to allow sub-units of code to build up in > : the gene, but which would not necessarily be present in the warrior unless > : a particular control gene was active. This might give a way for more > : advanced warriors to be evolved. > > One idea I was working with was creating "strategies" as genes. An > example would be a bomber; > I don't have any experience in GP, but I've had the idea of evolving programs for a long time. I recently wrote an emulator based on the OISC instruction set (OISC - One Instruction Set Computing. See http://locke.ccil.org/retro/ for more details), with plans on writing a programs for it which would evolve. I then wrote an assembler, and subsequently the emulator's first program/organism. The way it works is that the organism copies itsself to a random location. Each copy of each word has a chance of either skipping, repeating, or introducing an error. On each execution of an instruction, there's a small chance that the emulator will kill the process (i.e. death). The net effect (hopefully) will be that propegation and evolution occur. I haven't actually tested it yet, but I'm hopeful. Anyway, my point is that I was thinking: Why couldn't I make a game out of this evolution thing. It would basically be like corewar, except that you _have_ to reproduce. The goal would be to be the last program with surviving descendants. Now that I come to think of it, one strategy would be to keep spawning on top of your own code, so that dying threads wouldn't matter too much. Of course, it would be hard to maintain state in such a program... Anyway, what do you think? -marvin From: SKI Koth Server Subject: SKI-ICWS: Status - Multiwarrior Experimental 94 08/19/96 Date: 1996/08/19 Message-ID: <199608190400.AAA13398@odin.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 08/19/96 ****** NOTICE ****** We have changed our name to koth.org ****** NOTICE ****** See up to the second scores and the latest Core War information at : http://www.koth.org/~koth *FAQ* http://www.koth.org/~koth/corewar-faq.html Current Status of the StormKing Industries MultiWarrior Experimental 94 CoreWar Hill: Last battle concluded at : Thu Aug 15 08:11:20 EDT 1996 # Name Author Score Age 1 TimeScapeX (0.1) J. Pohjalainen 5544 62 2 This is Test1 Kurt Franke 5544 27 3 jaded M R Bremer 5544 33 4 Evolve X John Wilkinson 5544 2 5 Paper8 G. Eadon 5544 28 6 Paperone Beppe Bezzi 5522 47 7 Test2 George Eadon 5498 22 8 Newest test Pedro 5498 1 9 Fork v0.2-9p/51b Christoph C. Birk 5474 4 10 Gluttony J E Long 5408 20 11 Anthill 5 Planar 5195 24 12 Saat V2.01 S. Schroeder 5169 16 13 Shwing! T. H. Davies 5167 58 14 life Nandor Sieben 5122 63 15 Wait A Lot v0.1 Justin Kao 5106 7 16 Hidden M.C.Diskett Bullfrog 4873 32 17 Pommes-Ketchup V1.35 S. Schroeder 4821 11 18 Leviathan2 harleyQ2 4702 14 19 lifedwarf Nandor Sieben 4621 39 20 Variation M-1 Jay Han 4272 9 21 Leviathan harleyQ2 4182 15 From: SKI Koth Server Subject: SKI-ICWS: Status - Standard 08/19/96 Date: 1996/08/19 Message-ID: <199608190400.AAA13385@odin.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 08/19/96 ****** NOTICE ****** We have changed our name to koth.org ****** NOTICE ****** See up to the second scores and the latest Core War information at : http://www.koth.org/ *FAQ* http://www.koth.org/corewar-faq.html Current Status of the StormKing Industries Standard KotH CoreWar Hill : Last battle concluded at : Mon Aug 12 11:52:10 EDT 1996 # %W/ %L/ %T Name Author Score Age 1 40/ 36/ 24 PacMan v5 David Moore 144 18 2 29/ 16/ 55 CAPS KEY IS STUCK AGAIN Steven Morrell 143 116 3 31/ 21/ 48 Yop La Boum v2.1 P.E.M & E.C. 142 50 4 42/ 43/ 15 Iron Gate Wayne Sheppard 140 244 5 38/ 40/ 21 Beholder's Eye V1.7 W. Mintardjo 136 194 6 38/ 41/ 21 Stasis David Moore 135 26 7 24/ 13/ 64 ttti nandor sieben 134 100 8 25/ 17/ 59 K-test P.E.M 133 22 9 23/ 15/ 62 Simple '88 Ian Oversby 132 5 10 17/ 5/ 79 Evolve '88 John K Wilkinson 129 6 11 21/ 13/ 67 Cannonade P.Kline 129 150 12 22/ 16/ 61 Blue Funk 88 Steven Morrell 128 114 13 25/ 23/ 51 Test Wayne Sheppard 127 139 14 18/ 11/ 72 Imperfic II John Wilkinson 125 36 15 20/ 15/ 65 Peace Mr. Jones 124 124 16 32/ 39/ 29 Giskard v0.5 Ken Mitton 124 88 17 21/ 20/ 59 Hydra Stephen Linhart 123 224 18 33/ 43/ 24 Gisela 3G6 Andrzej Maciejczak 123 13 19 22/ 28/ 50 Big Bang Theory Zul Nadzri 116 14 20 9/ 21/ 70 test Pedro 97 1 21 17/ 74/ 8 Test Pedro 61 2 From: Erwin Hugo Achermann Subject: Artificial Redcode, resume Date: 1996/08/19 Message-ID: <199608190735.JAA18037@ru10.inf.ethz.ch>#1/1 newsgroups: rec.games.corewar Hi all, It's great that thread comes up. I would like to collect some thoughts that were expressed in this discussion so far and to push that discussion maybe one round further. > The GA tends to evolve warriors very robust to small changes. > Another idea is to design warriors with many useless instructions > (like NOP) to pad out the code and therefore make small changes to > values (eg. in JMP instructions) less likely to be fatal to the > warrior. These type of warriors will be very inefficient against > human designed opponents however. This is correct provided that the GA works on human-readable redcode directly. > I made that proposal the last time GAs were brought up. The thing > is, however, that if you start of with say a warrior of 100 nops > ... [stuff deleted] However, after time, the removal of the NOPs in > the middle of the loop would clear things up... Is there an archive where these old GA Discussions are available? This removal of superfluous NOPs isn't to be expected but after a very long time of computing. > > If you can really modularize a warrior's components, then you can > > just mix and match these modules. [stuff deleted] I envision 2 parts > > to a mutation : mutate the constants, or mutate the > > paper/stone/scanner/imp modules. > > The problem with this approach is that you are only using the GA to > optimise existing warriors. You aren't ever going to evolve a > fundamentally different piece of code, like a new type of attack. I agree partly. But the GA might very easily find some combinations of known modules that no human thought of and that nonetheless are quite successful. > Maybe better genetics could be simulated by encoding warriors at a > deeper level, where the genetic code is not directly related to the > warrior code, but rather codes for an algorithm to generate the > warrior. In my opinion this is the way to go: Consider the biological "set of instructions" its about 20 Amino acids (the words) that are coded (written) with Triplets of 4 DNA-bases (the letters). This is a very reduced instruction set, that make recombination and mutation a very robust operation. On the other hand, counting the instructions in redcode we get 10 opcodes x 6 modifiers x 6^2 address modes x 8000^2 addresses. If we only could get rid of the addresses somehow, we still have an instruction set of size 2160. This still makes redcode just the wrong kind of language to work on in terms of genetic operators such as mutations of instructions, modifiers and the like. Such operations will only be able to damage working code, but the will never be able to find new working piece of code. From another point of view: A new working piece of code has no neighborhood (in the redcode space) that is half as good. It's either working or it's worth nothing more than any other piece of random code. We have to melt these needles out of that big haystack by introducing a genetic code that is translated by an algorithm and thus produces viable redcode. Regards Erwin From: SKI Koth Server Subject: SKI-ICWS: Status - ICWS Experimental 94 08/19/96 Date: 1996/08/19 Message-ID: <199608190400.AAA13402@odin.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 08/19/96 ****** NOTICE ****** We have changed our name to koth.org ****** NOTICE ****** See up to the second scores and the latest Core War information at : http://www.koth.org/~koth *FAQ* http://www.koth.org/~koth/corewar-faq.html Current Status of the StormKing Industries ICWS Experimental 94 CoreWar Hill: Last battle concluded at : Thu Jul 25 11:26:51 EDT 1996 # %W/ %L/ %T Name Author Score Age 1 33/ 5/ 63 Evol Cap 4 X John Wilkinson 161 29 2 34/ 14/ 52 Rosebud Beppe 155 8 3 39/ 27/ 33 Falcon v0.3 X Ian Oversby 151 2 4 44/ 38/ 18 Illusion-94/55 Randy Graham 151 11 5 46/ 41/ 13 Tsunami v0.1 Ian Oversby 151 7 6 45/ 42/ 13 Memories Beppe Bezzi 148 36 7 41/ 35/ 25 BigBoy Robert Macrae 146 54 8 43/ 40/ 17 Frontwards v2 Steven Morrell 145 59 9 38/ 34/ 28 Lithium X 8 John K Wilkinson 143 20 10 41/ 42/ 17 Stepping Stone 94x Kurt Franke 141 15 11 39/ 38/ 24 Derision M R Bremer 139 46 12 41/ 45/ 14 Pagan John K W 137 14 13 42/ 49/ 9 S.E.T.I. 4-X JKW 136 30 14 30/ 26/ 44 Variation M-1 Jay Han 135 9 15 29/ 27/ 45 Aleph 1 Jay Han 131 19 16 36/ 45/ 19 Fire Master Xv1 JS Pulido 127 51 17 33/ 38/ 29 Tornado 2.0 x Beppe Bezzi 127 53 18 26/ 28/ 46 Hector 2 Kurt Franke 123 49 19 38/ 56/ 6 dodger component M R Bremer 119 1 20 33/ 50/ 16 Watcher-h Kurt Franke 116 48 21 33/ 50/ 18 Watcher Kurt Franke 116 52 From: SKI Koth Server Subject: SKI-ICWS: Status - MultiWarrior 94 08/19/96 Date: 1996/08/19 Message-ID: <199608190400.AAA13393@odin.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 08/19/96 ****** NOTICE ****** We have changed our name to koth.org ****** NOTICE ****** See up to the second scores and the latest Core War information at : http://www.koth.org/~koth *FAQ* http://www.koth.org/~koth/corewar-faq.html Current Status of the StormKing Industries Multiwarrior 94 CoreWar Hill: Last battle concluded at : Sun Aug 18 22:54:35 EDT 1996 # Name Author Score Age 1 Super Evol Cap John Wilkinson 5334 7 2 Son of Imp Steven Morrell 5322 43 3 Die Hard P.Kline 5322 30 4 Evol Cap -- John Wilkinson 5314 9 5 test_1 Pedro 5314 1 6 TESTI Maurizio Vittuari 5304 18 7 60% Cotton Wilkinson 5301 26 8 TJ Maurizio Vittuari 5277 19 9 test Pedro 5269 2 10 sisyphus Kafka 5259 8 11 test3 Anonymous 3508 0 From: SKI Koth Server Subject: SKI-ICWS: Status - ICWS Tournament 08/19/96 Date: 1996/08/19 Message-ID: <199608190400.AAA13389@odin.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 08/19/96 ****** NOTICE ****** We have changed our name to koth.org ****** NOTICE ****** See up to the second scores and the latest Core War information at : http://www.koth.org/~koth *FAQ* http://www.koth.org/~koth/corewar-faq.html Current Status of the StormKing Industries Annual ICWS Tournament CoreWar Hill: Last battle concluded at : Thu Aug 1 11:14:03 EDT 1996 # %W/ %L/ %T Name Author Score Age 1 43/ 11/ 46 Cannonade Paul Kline 175 94 2 50/ 33/ 17 Miss Carefree Derek Ross 166 26 3 43/ 34/ 23 Giskard v0.5 Ken Mitton 151 67 4 47/ 44/ 9 Agony T Stefan Strack 150 95 5 37/ 28/ 35 Pommes-Ketchup V1.35 S. Schroeder 146 7 6 31/ 16/ 53 Nothing Special G. Eadon 146 9 7 42/ 38/ 21 Old Tire Swing Randy Graham 145 51 8 31/ 19/ 50 Turkey Beppe Bezzi 143 10 9 41/ 41/ 18 Miss Carry Derek Ross 141 58 10 38/ 36/ 27 Yop La Boum v2.1 P.E.M & E.C. 140 24 11 33/ 31/ 36 Big Bang Theory Zul Nadzri 135 3 12 38/ 45/ 16 test88 P.Kline 132 13 13 28/ 25/ 47 One Fat Lady Robert Macrae 131 11 14 38/ 46/ 16 Slaver v1.1i Christoph C. Birk 129 55 15 37/ 48/ 15 Traper3_t Waldemar Bartolik 127 4 16 31/ 38/ 31 Beauty 1000 v 0.0 Pedro 125 1 17 34/ 46/ 20 Illusion Randy Graham 121 53 18 34/ 49/ 17 DoubleStone v0.7 Christoph C. Birk 120 37 19 36/ 56/ 7 xtc stefan roettger 116 99 20 26/ 39/ 35 Chris Steven Morrell 113 16 21 1/ 1/ 2 Beauty 1000 Pedro 6 2 From: Planar Subject: Re: Name that warrior Date: 1996/08/20 Message-ID: <4vc1mn$q8c@news-rocq.inria.fr> references: <4va9sf$9c4@hpscit.sc.hp.com> newsgroups: rec.games.corewar In article <4va9sf$9c4@hpscit.sc.hp.com>, jbui@scd.hp.com (Joseph Bui) writes: >I guess I'm really looking for a glossary. Let me try. Bombing: Moving a bomb to "random" placees in core. Most of the time, the "random" places are regularly spaced, using the core wrap-around to make them pseudo-random. The spacing between bombs is called the bombing step. The bombing pattern will eventually repeat itself. When this occurs, there may still be intervals between the bombs. These intervals all have the same length, which is called the modulo number for that bombing step (actually, the modulo number is one plus the number of unbombed locations in one interval). Bomb: An instruction (or group of instructions) that a warrior uses for bombing. Normal bombs are usually DAT, MOV, or MOD instructions. Many programs use the contents of a random core location as a bomb, because they color the core with increments or decrements. Stun bombs are sequences of instructions that cause the opponent to split a lot of processes, thus slowing down its other (useful) processes. Examples: SPL 0 was used in the past as a stun bomb, but it's considered too weak nowadays. The same holds for SPL 0 / JMP -1. Modern stun bombs are SPL 0/SPL -1/JMP -2, or SPL/MOV, tuned to create a carpet of SPL. Core clear/Clear: A piece of program that wipes the core sequentially (almost--see spiral clear) to make sure the opponent won't survive, even if reduced to a single instruction (such as SPL 0 or JMP 0). The simplest core clears are single-pass: they wipe the core with DATs, then commit suicide or turn themselves into imp gates. Repeating core clears will clear the core over and over (generally with DATs). SPL/DAT core clears start by clearing with SPL 0, then with DAT. The SPL/SPL/DAT core clear does two passes of SPL before the DATs. The d-clear, or dirty-clear speeds up the clear by clearing with a "random" mix of DATs and decrements. Spiral clear: A core clear that doesn't quite wipe the core sequentially, but uses the same spiral pattern as imp spirals, in order to kill them efficiently. Scanning: Looking at core locations, searching for anything that is not the initial core value. The choice of scanning patterns is similar to bombing patterns. There are two forms of scanning: zero-scanning compares core locations' fields with zero, and CMP-scanning compares two core locations together. CMP-scanning is generally faster than bombing, and you're throwing fewer bombs, so you can use more complex bombs (i.e. two- and three-instruction bombs) without slowing down too much. Coloring: A technique used against scanners: using the postincrement or predecrement addressing mode to change core locations as fast as possible, so the scanner will spend its time bombing your bombs. Also, decrementing or incrementing an instruction will sometimes kill (or cripple) the opponent. DJN-stream: If your code includes a loop, you can replace the final JMP instruction with a DJN with a predecremented B operand. This will decrement a sequence of adjacent locations in core. This sequence is called the DJN-stream. The stream will color the core, and it can cripple an opponent. Some warriors detect an incoming DJN-stream and counter-attack; Paul Kline is the expert of this technique. Booting/Boot and decoy: Another technique used against scanners. If your warrior is much smaller than the maximum number of instructions (typically 100), you can put useless (but visible) instructions in the extra space to divert the scanner's attacks. These are called the decoy. Since you don't want to be anywhere near the decoy when the scanner attacks it, you add a small routine to copy your warrior away before starting the copy. This process of copying away is called booting. Don't forget to erase the pointers used by your copy routine, because some scanners can follow these pointers and find your booted warrior. Quick scanning: A technique used against big warriors, including boot-and-decoy warriors. If the opponent is 100 instructions long, you can find it by scanning one location in 100. With a 8000 locations core, this is only 40 comparisons. Unroll the loop of CMP-scanner and you get a quick-scanner, guaranteed to find the opponent in 40 cycles. By performing an early-out test, you'll sometimes find the opponent even faster. This works well against warriors that don't boot quickly, especially p-spacers. Q^2 scanning: A way of performing the early-out test of a quick-scanning more often, optimising the quick-scanning speed. Decoy-making: Instead of having a built-in decoy in your warrior, you can make one at the very start of the battle. One MOV instruction can change three core locations, so decoy-making is very fast. Imp/Imp spiral/Imp ring: IMP is the simplest warrior: MOV 0,1 copies itself one location forward and "jumps" (actually falls through) into the copy. Imp rings, invented by Anders Ivner, generalise this idea with a multi-process warrior composed of MOV instructions. Each process copies itself into the instruction that will be executed by the next thread. Imp spirals are very much like rings. They are all easier to understand than explain. See chapter 1 of Steven Morrell's "My First Corewar Book" for a good explanation. Imp launch: The piece of code that is used to build a working ring or spiral by splitting the processes and jumping them to the right place in core (they must be carefully synchronised or the spiral won't work). Gate/Imp gate: A piece of code that changes (overwrites, decrements, or increment) the same core location at each cycle. Very effective against imps, rings, and spirals, and mostly useless against anything else. Used as an end-game component. Gate-crashing spiral: A combination of rings and spirals that can pass through a gate. Stun bomb: see Bomb Self-splitting: Used to make a warrior resistant to stun bombs. A self-splitting warrior uses a SPL instruction to accumulate processes in its main loop, so it won't be slowed down too much (or at all) by a stun bomb dropped on its other components. P-spacer/Switcher: A warrior that uses p-space to remember the results of past battles and uses this information to select a different strategy for each battle. Paper: A warrior that makes several copies of itself and launches them. Note that an imp is not a paper because it only makes one copy of itself. Papers are naturally self-splitting because they grow exponentially. Most papers carry a payload that can be a bomber, an anti-vampire bomber, an imp spiral, etc. Vampire: A bomber or scanner that uses as bombs a JMP instruction pointing to a piece of its own code (called the pit) that the opponent will execute. Most pits will stun the opponent by splitting many processes. They can also do other work, like participating in a core clear. Executing the opponent's code: This technique doesn't have a name because it's not aggressive enough to be useful under the current rules. Most warriors won't kill themselves, so you can't kill them by executing their code. Moreover, executing a vampire's code can be a very bad idea. Self-repairing/Error correcting This technique never gave an efficient warrior. It seems that self-repairing warriors spend too much time monitoring and repairing themselves, and not enough attacking. Moreover, self-repairing warriors don't seem to be able to repair quickly enough when damaged. If you're a beginner, I'd recommend starting with something simpler. A good warrior must be short (13 instructions is big). -- Planar From: Ross Morgan-Linial Subject: (very long) Re: Artificial Life, Redcode, & Tierra Date: 1996/08/20 Message-ID: #1/1 references: <840528686.28426.0@ogham.demon.co.uk> newsgroups: rec.games.corewar On Tue, 20 Aug 1996 neil@ogham.demon.co.uk wrote: // Erwin Hugo Achermann wrote: // >big question is: How should i represent a warrior? If your mutations // >and crossover work on the Redcode directly (eg change a modifier, // >change a mov into a spl, cut two warriors into pieces and shuffle // >etc.) A successful mutation/crossover is !!very~very! unlikely. But on // // I think here youve hit the fundemental problem with trying to create // "evolved" computer code. In real genetics DNA codes for RNA which the codes // proteins. If you change one of the DNA sequences slightly the end resultant // protein will still do *more or less* what it did before but either slightly // better or worse. In computer code this is pretty unlikely as code by its // very nature is a logic machine and needs to be pretty exact, as any programmer // knows if you change one instruction slightly the whole program can go south. // I'm not saying its impossible to do with code , just very difficult. A far // simpler method to use is the probabilities method where the programs "genes" // are a list of *probabilities* of a particular piece of prewritten code or // action being carried out per tick of the overall control program... This could // probably be mapped onto a corewars scenario somehow... // // NJR Actually, you can get very good evolution using code. Look at Tierra. The key thing that makes Tierra work is that there are no numeric values in the codes. All jumps are done by looking for matching templates, and numbers are coded with a series of shifts and bit-flips. Overall, a mutation well probably be harmful, but not neccessarily fatal, and enough good mutations happen to keep the system evolving. Perhaps a GA could use an "enriched instruction set" including template instructions (not translated to redcode), several different opcodes translating to a single redcode opcode (mov.i & mov.b, for instance), etc. For templates, you'd need four instrutions, not translated to redcode: nop00, nop01, nop10, nop11 where the first # is the a-template and the second the b-template. To seperate templates, you need a "skip" instruction, which doesn't get translated, and does nothing. For addressing modes, you could use a-ind, a-ind+, a-ind-, a-imm, b-ind, b-ind+, b-ind-, and b-imm. Whether it would be a-indirect or b-indirect would be determined by whether it points to an a-template or b-template. For opcode modifiers, a/b/ab/ba would be chosen by which template. x/f would be caused by a "both" prefix opcode, and i by a "full" prefix opcode. For numbers, you would need a-swp, a-shl, b-swp, and b-shl to flip the lowest bit/shift left. These would override the number, but not addressing modes, etc. of the instruction. Finally, you need a start instruction, which would act sort of like a jump - the first start is the one used. Okay, first we have all redcode instructions, and these non-instructions: nop00 nop01 nop10 nop11 skip a-ind a-ind+ a-ind- a-imm b-ind b-ind+ b-ind- b-imm both full a-swp a-shl b-swp b-shl start So here would be Dwarf: start nop11 nop00 nop00 skip nop00 nop01 nop10 a-shl b-shl dat nop00 nop11 nop11 b-ind full mov nop11 nop10 nop01 a-imm a-swp a-shl a-shl add nop11 nop10 nop01 jmp nop11 nop00 nop00 Which translates to: dat.b 0, 0 start mov.i -1, @-1 add.ab #4, -2 jmp.b -2, -2 Did _anyone_ else understand what I was saying? ------ Ross Morgan-Linial * rmorganl@fhcrc.org It's easier to do a stupid thing stupidly than an intelligent thing intelligently. From: David A Johnston Subject: Re: Artificial Life, Redcode, & Tierra Date: 1996/08/20 Message-ID: #1/1 newsgroups: rec.games.corewar > > Anyway, my point is that I was thinking: Why couldn't I make a game > > out of this evolution thing. It would basically be like corewar, except > > that you _have_ to reproduce. The goal would be to be the last program > > with surviving descendants. > > > > Now that I come to think of it, one strategy would be to keep spawning > > on top of your own code, so that dying threads wouldn't matter too much. > > Of course, it would be hard to maintain state in such a program... > > > > Anyway, what do you think? > > Supposedly corewars has its roots in a game very similar to this. Well, the original article said that A.K. Dewdney got the idea from the thought of a program which was written to eliminate viruses in a system. He had a picture in his mind of programs duking it out in the core. -marvin /*-------------------------------------------------------*/ a(m,W)float m,W;{int e=1;float p,Q,n;p=m;Q=W;while(e++<126) {n=p;p=p*p-Q*Q+m;Q=2*n*Q+W;if((p*p+Q*Q)>=4)return e;}return 0;}main(){float _,E=1.5;while((E-=0.130434783)>-1.5){for(_= (-2);_<1;_+=0.037974684)putchar(a(_,E)+32);putchar('\n');}} From: Brian Haskin Subject: Re: Artificial Life, Redcode, & Tierra Date: 1996/08/20 Message-ID: #1/1 newsgroups: rec.games.corewar On Tue, 20 Aug 1996, David A Johnston wrote: > > Anyway, my point is that I was thinking: Why couldn't I make a game > out of this evolution thing. It would basically be like corewar, except > that you _have_ to reproduce. The goal would be to be the last program > with surviving descendants. > > Now that I come to think of it, one strategy would be to keep spawning > on top of your own code, so that dying threads wouldn't matter too much. > Of course, it would be hard to maintain state in such a program... > > Anyway, what do you think? Supposedly corewars has its roots in a game very similar to this. > > -marvin > Brian Haskin From: bremermr@cartoon.ecn.purdue.edu (Myer R. Bremer) Subject: Core Warrior Date: 1996/08/20 Message-ID: <4vdgrk$j46@mozo.cc.purdue.edu>#1/1 newsgroups: rec.games.corewar greetings all. still seems like hill traffic is a bit slow. in the past TWO weeks, i only have around five successful challenges, just one in the last week. so i'm still holding out on the next issue. i know those of you who just put warriors on the hill are dying for some recognition. you'll get your due. but until then: send up some warriors! m r bremer From: neil@ogham.demon.co.uk Subject: Re: Artificial Life, Redcode, & Tierra Date: 1996/08/20 Message-ID: <840528686.28426.0@ogham.demon.co.uk>#1/1 newsgroups: rec.games.corewar Erwin Hugo Achermann wrote: >big question is: How should i represent a warrior? If your mutations >and crossover work on the Redcode directly (eg change a modifier, >change a mov into a spl, cut two warriors into pieces and shuffle >etc.) A successful mutation/crossover is !!very~very! unlikely. But on I think here youve hit the fundemental problem with trying to create "evolved" computer code. In real genetics DNA codes for RNA which the codes proteins. If you change one of the DNA sequences slightly the end resultant protein will still do *more or less* what it did before but either slightly better or worse. In computer code this is pretty unlikely as code by its very nature is a logic machine and needs to be pretty exact, as any programmer knows if you change one instruction slightly the whole program can go south. I'm not saying its impossible to do with code , just very difficult. A far simpler method to use is the probabilities method where the programs "genes" are a list of *probabilities* of a particular piece of prewritten code or action being carried out per tick of the overall control program... This could probably be mapped onto a corewars scenario somehow... NJR From: jklewis@ren.us.itd.umich.edu (John K. Lewis) Subject: Re: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 1996/08/22 Message-ID: <4viihg$fce@lastactionhero.rs.itd.umich.edu>#1/1 references: newsgroups: rec.games.corewar Stefan Strack (stst@vuse.vanderbilt.edu) wrote: Have you received the altered copy of the FAQ I sent you? It really needs to be updated so if you can take a look at it and tell me how far off it is that would be great. From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 1996/08/22 Message-ID: newsgroups: rec.games.corewar,rec.answers,news.answers Archive-name: games/corewar-faq Last-Modified: 95/10/12 Version: 3.6 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) pmars08s.zip - portable system, ICWS'88 and '94, runs on UNIX, PC, Mac, Amiga. C source archive pmars08s.tar.Z - same as above pmars08.zip - PC executables with graphics display, req 386+ macpmars02.sit.hqx - pMARS executable for Mac (port of version 0.2) buggy, no display MacpMARS1.99a.cpt.hqx - port of v0.8 for the Mac, with display and debugger MacpMARS1.0s.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.8, 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 L2, 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.6 1995/10/12 22:44:37 stst Exp stst $ From: Ross Morgan-Linial Subject: Pizza seems to be down :-( Date: 1996/08/22 Message-ID: #1/1 newsgroups: rec.games.corewar Well, Pizza appears to be down. All my messages get bounced with a message saying there is no such user. I'm pretty sure it's not just my computer. I wonder if the account was revoked, or something? I hope this gets fixed soon :-( ------ Ross Morgan-Linial * rmorganl@fhcrc.org Any man who goes to a psychiatrist ought to have his head examined. - Samuel Goldwyn From: Robert Macrae Subject: Re: Artificial Life, Redcode, & Tierra Date: 1996/08/23 Message-ID: <4vle9s$b8n@soap.news.pipex.net>#1/1 references: <840528686.28426.0@ogham.demon.co.uk> newsgroups: rec.games.corewar neil@ogham.demon.co.uk wrote: >... A far simpler method to use is the probabilities method where the > programs "genes" are a list of *probabilities* of a particular piece of > prewritten code or action being carried out per tick of the overall > control program... This could probably be mapped onto a corewars > scenario somehow... Sounds like an interesting way to smooth a search-space which has sharp minima, but don't you end up with an enormous extra computional burden? I think you need to calculate a large number of fitnesses _per_individual_ to integrate over the probability space; does this gain anything compared to just having a larger population? From: jklewis@ren.us.itd.umich.edu (John K. Lewis) Subject: Product of GA Date: 1996/08/23 Message-ID: <4vkp87$886@lastactionhero.rs.itd.umich.edu>#1/1 newsgroups: rec.games.corewar Below is a product of the GA I am testing. It beats twill consistantly. [the names of all the programs in my GA are randomly picked from a wordlist. I wish I could have named a real program saint.] Feedback welcome. (like someone testing this for wilkies) ;name saint ;assert 1 ORG START START DIV.F < 1, @ 0 DIV.F # 3, > 4 SLT.BA > -2, # 3 SPL.F $ 1, { 2 SPL.BA # 4, * -1 SPL.A # -2, > 1 MOV.X < -1, { 1 DJN.F $ 4, < -2761 JMN.A # 7, < 2 SPL.A { -2, > -1 SPL.AB # 2152, { -4 MOV.BA > -3918, > 2 DJN.F $ 4, < -2761 CMP.B * 4, # -3375 SPL.BA < -1, $ 2 ADD.F > 5, $ -2 DIV.F # 3, > 4 SLT.BA > -2, # 3 SPL.F $ 1, { 2 SPL.BA # 4, * -1 SPL.A # -2, > 1 MOV.X < -1, { 1 DJN.F $ 4, < -2761 JMN.A # 7, < 2 CMP.F $ 1, { 2 SPL.A { -2, > -1 JMP.B < 1, { 1017 DIV.X # 0, { -1619 SPL.BA < -1, $ 2 ADD.F > 5, $ -2 DJN.F $ 4, < -2761 CMP.B * 4, # -3375 CMP.F @ 3, { -3 ADD.BA * 5, # 4 DJN.F $ 4, < -2761 CMP.B * 4, # -3375 CMP.F @ 3, { -3 DJN.F $ 4, < -2761 CMP.B * 4, # -3375 CMP.F @ 3, { -3 ADD.BA * 5, # 4 MUL.A > 4, < 4 CMP.F @ 3, { -3 CMP.F $ 1, { 2 SPL.A { -2, > -1 DJN.F $ 4, < -2761 CMP.B * 4, # -3375 CMP.F @ 3, { -3 CMP.F @ 3, { -3 ADD.F > 5, $ -2 CMP.AB # 713, * 0 JMN.A # 7, < 2 DJN.F $ 4, < -2761 DIV.F # 3, > 4 SLT.BA > -2, # 3 SPL.F $ 1, { 2 SPL.BA # 4, * -1 SPL.A # -2, > 1 MOV.X < -1, { 1 DJN.F $ 4, < -2761 JMN.A # 7, < 2 CMP.F $ 1, { 2 SPL.A { -2, > -1 JMZ.B $ 2, * 31 JMN.A # 7, < 2 CMP.F $ 1, { 2 DJN.F $ 4, < -2761 DJN.X > 1, # -2379 MOV.B > 1, > 1 JMN.A # 7, < 2 SPL.F $ 1, { 2 SPL.F $ 1, { 2 SPL.BA # 4, * -1 SPL.A # -2, > 1 MOV.X < -1, { 1 SPL.F $ 1, { 2 SPL.BA # 4, * -1 SPL.A # -2, > 1 MOV.X < -1, { 1 DJN.F $ 4, < -2761 JMN.A # 7, < 2 MOV.X < -1, { 1 DJN.F $ 4, < -2761 CMP.AB # 713, * 0 JMN.A # 7, < 2 CMP.F $ 1, { 2 DIV.F # 3, > 4 SLT.BA > -2, # 3 SPL.F $ 1, { 2 SPL.BA # 4, * -1 SPL.A # -2, > 1 MOV.X < -1, { 1 DJN.F $ 4, < -2761 JMN.A # 7, < 2 CMP.F $ 1, { 2 JMN.A # 7, < 2 CMP.F $ 1, { 2 SPL.A { -2, > -1 JMP.B < 1, { 1017 DIV.X # 0, { -1619 From: guenzel@extern.lrz-muenchen.de (Bjoern Guenzel) Subject: Re: RedCode Date: 1996/08/23 Message-ID: <4vjq9p$2lt@sparcserver.lrz-muenchen.de>#1/1 references: newsgroups: rec.games.corewar karl.castle@Ace.net.au wrote: >;redcode-b >;name Pit-Scanner v1.2 >;author Karl Castle >;assert 1 >PIT JMP PIT >AD ADD #8, SCAN >;I'm a _beginner_, but I'm writing this. >;the warrior jmp-bombs enemy processes, >;stopping them in their tracks. >;What do I do to switch execution to SC2 ? >SCAN JMZ AD, 13 >ATTACK MOV PIT, @SCAN > JMP AD >BOMB DAT #0, #0 >S2 ADD #4, SC2 >SC2 JMZ S2, -2 >ATT MOV BOMB, @SCAN > JMP S2 > END AD >If you can help, thankyou. >Karl Castle, karl.castle@ace.net.au Let's try. For the switch to SC2 there is a frequently used method for scanners. Your pit has the form jmp #0,0, therefore you could replace the jmp AD with jmn AD,hit. hit should be the last location you want to scan. For example pit jmp #0,<0 ad add.ab #8,scan scan jmz ad,attack+8 ;the startvalue assures that if you hit yourself, it is ;'attack' you find attack mov.i pit,@scan ;better don't forget the '.i'-operator new jmn.f ad, attack ;falls through when pit has been written to attack ... Now for the second part of your warrior. I am not sure if I understand what it is about. Am I right that it is a second jmz scanner, only this time bombing with dat instead of jmp? This is not very effective! Better try a simple (linear) coreclear, which is possibly smaller and has the advantage of hitting every location of Core finally. I think in your version now, you leave a lot of holes in Core, so the enemy might survive with a spl #0,0 or something. Also your steps could be better. Have you read Steven Morrels Stones tutorial? It lists some good step rates, and it is a must to read... Good luck! Bjoern From: jklewis@ren.us.itd.umich.edu (John K. Lewis) Subject: Possible new FAQ... comments needed. Date: 1996/08/23 Message-ID: <4vkjhe$5qa@lastactionhero.rs.itd.umich.edu> newsgroups: rec.games.corewar WARNING.-.WARNING.-.WARNING.-.WARNING.-.WARNING.-.WARNING.-.WARNING -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This is not the FAQ. This is a proposed change, and is not official. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- WARNING.-.WARNING.-.WARNING.-.WARNING.-.WARNING.-.WARNING.-.WARNING Archive-name: games/corewar-faq Last-Modified: 96/8/8 Version: 3.6 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? 8. What is Core Warrior? 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? 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 lot has changed. The current competitions in Core War use an extended version of the 94 standard. The current version of PMARS contains text files explaining the changes. [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. [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 Core Warrior? Following in the tradition of the Core War News Letter, Push Off, and The 94 Warrior, Core Warrior is a newsletter about strategies and current standings in Core War. Started in Oct.1995, back issues of Core Warrior (and the other newsletters) are available at . [ToC] _________________________________________________________________ Where are the Core War archives? Planar web page contains a large number of published warriors. Currently, all warriors published are included in this archive. [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) pmars08s.zip - portable system, ICWS'88 and '94, runs on UNIX, PC, Mac, Amiga. C source archive pmars08s.tar.Z - same as above pmars08.zip - PC executables with graphics display, req 386+ macpmars02.sit.hqx - pMARS executable for Mac (port of version 0.2) buggy, no display MacpMARS1.99a.cpt.hqx - port of v0.8 for the Mac, with display and debugger MacpMARS1.0s.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 . Planars Page is With a US mirror at [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, your warrior battles against each of the 25 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 three sites: "koth@stormking.com" is maintained by Scott J. Ellentuch (tuc@stormking.com), "pizza@ecst.csuchico.edu" by Thomas H. Davies (sd@ecst.csuchico.edu) and "koth@wastedyouth.umich.edu" by Andrew Fabbro and Johk K. Lewis (koth@umich.edu).To conserve resources, the different hill types are divided up among the sites. The way you submit warriors to the KotHs is pretty much the same. Therefore, the entry rules described below apply to both "pizza", "stormking", and "wastedyouth" 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 eight separate hills you can select by starting your program with ;redcode-b, ;redcode-94, ;redcode-94x, ;redcode, ;redcode-icws, ;redcode-94m, ;redcode-94xm, or ;recode-94lp. The former three run at "pizza", the next four at "stormking" and the last is on "wastedyouth". More information on these hills is listed below. 3) Mail this file to koth@koth.org, pizza@ecst.csuchico.edu or koth@wastedyouth.umich.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 25 (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. Most hills have some way of checking the queue. 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 25 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 25 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: 25 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: 25 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: 25 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 ICWS'94 Limited Process Hill: (Accessed with ";redcode-94lp", available at "wastedyouth") hillsize: 25 warriors rounds: 200 coresize: 8000 max. processes: 8 duration: after 800,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.8, a platform-independent corewar system available at ftp.csua.berkeley.edu. The '94 and '94x hills allow five experimental opcodes and three addressing modes currently not covered in the ICWS'94 draft document: LDP - Load P-Space STP - Store P-Space 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 L2, 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 _________________________________________________________________ From: Justin Kao <102741.2022@CompuServe.COM> Subject: Pro hill Date: 1996/08/25 Message-ID: <960825212154_102741.2022_GHT140-1@CompuServe.COM>#1/1 newsgroups: rec.games.corewar Can anyone help me with getting onto the -94 hill? Both my coreclears which do reasonably well on Wilkies and the beginner hill did _very_ badly when I sent them to the pro hill. When it was working that is... :( Anyway, just wondering there seems to be other things important to doing well on the -94 hill that aren't important on Wilkies and the beginner hill. Justin From: birk@nica.mpia-hd.mpg.de (Christoph C. Birk) Subject: Re: Product of GA Date: 1996/08/26 Message-ID: <199608261546.RAA10223@nica.mpg.de>#1/1 newsgroups: rec.games.corewar 'saint' gets a score of 57 Wilkies and would reach rank 246 out of 283 on the '94-Koenigstuhl. Christoph From: David A Johnston Subject: Re: Artificial Life, Redcode, & Tierra Date: 1996/08/26 Message-ID: <32222AC7.41C67EA6@pogo.wv.tek.com>#1/1 references: <840528686.28426.0@ogham.demon.co.uk> <4vle9s$b8n@soap.news.pipex.net> newsgroups: rec.games.corewar > Sounds like an interesting way to smooth a search-space which has sharp > minima, but don't you end up with an enormous extra computional burden? I > think you need to calculate a large number of fitnesses _per_individual_ > to integrate over the probability space; does this gain anything compared > to just having a larger population? This all sounds incredibly complicated to me. I've always found that one of the great beauties and advantages of evolution is its simplicity. The thing is that in real life, it's not some outside force that's mutating genes, but rather the genes themselves. So why not build programs that modify themselves, according to their own algorithm? This is the sort of thing Tierra does, as near as I can tell. This allows the mutation algorithm to change as well, to become better suited to its environment. -marvin From: SKI Koth Server Subject: SKI-ICWS: Status - ICWS Experimental 94 08/26/96 Date: 1996/08/26 Message-ID: <199608260400.AAA07932@odin.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 08/26/96 ****** NOTICE ****** We have changed our name to koth.org ****** NOTICE ****** See up to the second scores and the latest Core War information at : http://www.koth.org/~koth *FAQ* http://www.koth.org/~koth/corewar-faq.html Current Status of the StormKing Industries ICWS Experimental 94 CoreWar Hill: Last battle concluded at : Thu Jul 25 11:26:51 EDT 1996 # %W/ %L/ %T Name Author Score Age 1 33/ 5/ 63 Evol Cap 4 X John Wilkinson 161 29 2 34/ 14/ 52 Rosebud Beppe 155 8 3 39/ 27/ 33 Falcon v0.3 X Ian Oversby 151 2 4 44/ 38/ 18 Illusion-94/55 Randy Graham 151 11 5 46/ 41/ 13 Tsunami v0.1 Ian Oversby 151 7 6 45/ 42/ 13 Memories Beppe Bezzi 148 36 7 41/ 35/ 25 BigBoy Robert Macrae 146 54 8 43/ 40/ 17 Frontwards v2 Steven Morrell 145 59 9 38/ 34/ 28 Lithium X 8 John K Wilkinson 143 20 10 41/ 42/ 17 Stepping Stone 94x Kurt Franke 141 15 11 39/ 38/ 24 Derision M R Bremer 139 46 12 41/ 45/ 14 Pagan John K W 137 14 13 42/ 49/ 9 S.E.T.I. 4-X JKW 136 30 14 30/ 26/ 44 Variation M-1 Jay Han 135 9 15 29/ 27/ 45 Aleph 1 Jay Han 131 19 16 36/ 45/ 19 Fire Master Xv1 JS Pulido 127 51 17 33/ 38/ 29 Tornado 2.0 x Beppe Bezzi 127 53 18 26/ 28/ 46 Hector 2 Kurt Franke 123 49 19 38/ 56/ 6 dodger component M R Bremer 119 1 20 33/ 50/ 16 Watcher-h Kurt Franke 116 48 21 33/ 50/ 18 Watcher Kurt Franke 116 52 From: SKI Koth Server Subject: SKI-ICWS: Status - Multiwarrior Experimental 94 08/26/96 Date: 1996/08/26 Message-ID: <199608260400.AAA07924@odin.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 08/26/96 ****** NOTICE ****** We have changed our name to koth.org ****** NOTICE ****** See up to the second scores and the latest Core War information at : http://www.koth.org/~koth *FAQ* http://www.koth.org/~koth/corewar-faq.html Current Status of the StormKing Industries MultiWarrior Experimental 94 CoreWar Hill: Last battle concluded at : Thu Aug 15 08:11:20 EDT 1996 # Name Author Score Age 1 TimeScapeX (0.1) J. Pohjalainen 5544 62 2 This is Test1 Kurt Franke 5544 27 3 jaded M R Bremer 5544 33 4 Evolve X John Wilkinson 5544 2 5 Paper8 G. Eadon 5544 28 6 Paperone Beppe Bezzi 5522 47 7 Test2 George Eadon 5498 22 8 Newest test Pedro 5498 1 9 Fork v0.2-9p/51b Christoph C. Birk 5474 4 10 Gluttony J E Long 5408 20 11 Anthill 5 Planar 5195 24 12 Saat V2.01 S. Schroeder 5169 16 13 Shwing! T. H. Davies 5167 58 14 life Nandor Sieben 5122 63 15 Wait A Lot v0.1 Justin Kao 5106 7 16 Hidden M.C.Diskett Bullfrog 4873 32 17 Pommes-Ketchup V1.35 S. Schroeder 4821 11 18 Leviathan2 harleyQ2 4702 14 19 lifedwarf Nandor Sieben 4621 39 20 Variation M-1 Jay Han 4272 9 21 Leviathan harleyQ2 4182 15 From: SKI Koth Server Subject: SKI-ICWS: Status - ICWS Tournament 08/26/96 Date: 1996/08/26 Message-ID: <199608260400.AAA07916@odin.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 08/26/96 ****** NOTICE ****** We have changed our name to koth.org ****** NOTICE ****** See up to the second scores and the latest Core War information at : http://www.koth.org/~koth *FAQ* http://www.koth.org/~koth/corewar-faq.html Current Status of the StormKing Industries Annual ICWS Tournament CoreWar Hill: Last battle concluded at : Thu Aug 1 11:14:03 EDT 1996 # %W/ %L/ %T Name Author Score Age 1 43/ 11/ 46 Cannonade Paul Kline 175 94 2 50/ 33/ 17 Miss Carefree Derek Ross 166 26 3 43/ 34/ 23 Giskard v0.5 Ken Mitton 151 67 4 47/ 44/ 9 Agony T Stefan Strack 150 95 5 37/ 28/ 35 Pommes-Ketchup V1.35 S. Schroeder 146 7 6 31/ 16/ 53 Nothing Special G. Eadon 146 9 7 42/ 38/ 21 Old Tire Swing Randy Graham 145 51 8 31/ 19/ 50 Turkey Beppe Bezzi 143 10 9 41/ 41/ 18 Miss Carry Derek Ross 141 58 10 38/ 36/ 27 Yop La Boum v2.1 P.E.M & E.C. 140 24 11 33/ 31/ 36 Big Bang Theory Zul Nadzri 135 3 12 38/ 45/ 16 test88 P.Kline 132 13 13 28/ 25/ 47 One Fat Lady Robert Macrae 131 11 14 38/ 46/ 16 Slaver v1.1i Christoph C. Birk 129 55 15 37/ 48/ 15 Traper3_t Waldemar Bartolik 127 4 16 31/ 38/ 31 Beauty 1000 v 0.0 Pedro 125 1 17 34/ 46/ 20 Illusion Randy Graham 121 53 18 34/ 49/ 17 DoubleStone v0.7 Christoph C. Birk 120 37 19 36/ 56/ 7 xtc stefan roettger 116 99 20 26/ 39/ 35 Chris Steven Morrell 113 16 21 1/ 1/ 2 Beauty 1000 Pedro 6 2 From: SKI Koth Server Subject: SKI-ICWS: Status - Standard 08/26/96 Date: 1996/08/26 Message-ID: <199608260400.AAA07912@odin.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 08/26/96 ****** NOTICE ****** We have changed our name to koth.org ****** NOTICE ****** See up to the second scores and the latest Core War information at : http://www.koth.org/ *FAQ* http://www.koth.org/corewar-faq.html Current Status of the StormKing Industries Standard KotH CoreWar Hill : Last battle concluded at : Wed Aug 21 23:59:50 EDT 1996 # %W/ %L/ %T Name Author Score Age 1 44/ 41/ 15 Iron Gate Wayne Sheppard 148 244 2 40/ 35/ 25 PacMan v5 David Moore 145 18 3 41/ 38/ 20 Beholder's Eye V1.7 W. Mintardjo 144 194 4 32/ 20/ 48 Yop La Boum v2.1 P.E.M & E.C. 144 50 5 40/ 38/ 22 Stasis David Moore 143 26 6 27/ 16/ 57 CAPS KEY IS STUCK AGAIN Steven Morrell 139 116 7 22/ 13/ 65 ttti nandor sieben 131 100 8 35/ 40/ 24 Gisela 3G6 Andrzej Maciejczak 130 13 9 22/ 15/ 64 Simple '88 Ian Oversby 128 5 10 33/ 37/ 30 Giskard v0.5 Ken Mitton 128 88 11 22/ 17/ 61 K-test P.E.M 128 22 12 21/ 16/ 62 Blue Funk 88 Steven Morrell 125 114 13 19/ 13/ 69 Cannonade P.Kline 125 150 14 24/ 24/ 52 Test Wayne Sheppard 124 139 15 17/ 11/ 72 Imperfic II John Wilkinson 123 36 16 19/ 15/ 66 Peace Mr. Jones 122 124 17 13/ 5/ 82 Evolve '88 John K Wilkinson 122 6 18 20/ 20/ 60 Hydra Stephen Linhart 121 224 19 21/ 28/ 50 Big Bang Theory Zul Nadzri 114 14 20 6/ 21/ 74 test Pedro 91 1 21 3/ 62/ 35 Psy 2.0 J.Walter 45 0 From: SKI Koth Server Subject: SKI-ICWS: Status - MultiWarrior 94 08/26/96 Date: 1996/08/26 Message-ID: <199608260400.AAA07920@odin.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 08/26/96 ****** NOTICE ****** We have changed our name to koth.org ****** NOTICE ****** See up to the second scores and the latest Core War information at : http://www.koth.org/~koth *FAQ* http://www.koth.org/~koth/corewar-faq.html Current Status of the StormKing Industries Multiwarrior 94 CoreWar Hill: Last battle concluded at : Sun Aug 18 22:54:35 EDT 1996 # Name Author Score Age 1 Super Evol Cap John Wilkinson 5334 7 2 Son of Imp Steven Morrell 5322 43 3 Die Hard P.Kline 5322 30 4 Evol Cap -- John Wilkinson 5314 9 5 test_1 Pedro 5314 1 6 TESTI Maurizio Vittuari 5304 18 7 60% Cotton Wilkinson 5301 26 8 TJ Maurizio Vittuari 5277 19 9 test Pedro 5269 2 10 sisyphus Kafka 5259 8 11 test3 Anonymous 3508 0 From: Justin Kao <102741.2022@CompuServe.COM> Subject: Re: Artificial Life, Redcode, & Tierra Date: 1996/08/27 Message-ID: <960828011621_102741.2022_GHT140-1@CompuServe.COM>#1/1 newsgroups: rec.games.corewar >TV years back which uses probabilities to control some little bugs which exist >on a 2-D wraparound plain and can move in all directions within it. They can >... I think Dewdney wrote an article about that too... :-) Except I don't remember any sleeping bugs or muderous bugs in his version... Justin From: Justin Kao <102741.2022@CompuServe.COM> Subject: Hills working? Date: 1996/08/27 Message-ID: <960828024556_102741.2022_GHT144-1@CompuServe.COM>#1/1 newsgroups: rec.games.corewar Does anybody know when the Pizza hills will be working? Also, is the Limited Process hill down too? I sent a program there about 2 hours ago.... Justin From: SADKO.ARCADE@sovcust.sprint.com Subject: unsubscribe Date: 1996/08/27 Message-ID: #1/1 newsgroups: rec.games.corewar From: francis.irving@vegauk.co.uk (Francis Irving) Subject: Re: Artificial Life, Redcode, & Tierra Date: 1996/08/27 Message-ID: <32232e5f.6615716@news.demon.co.uk>#1/1 references: <841149860.10179.0@ogham.demon.co.uk> newsgroups: rec.games.corewar,comp.ai.alife On Tue, 27 Aug 1996 12:44:20 GMT, neil@ogham.demon.co.uk wrote: >Apologies beforehand as this is going somewhat off-topic... >I'm currently writing a simple alife/GA program based on something I saw on >TV years back which uses probabilities to control some little bugs which exist >on a 2-D wraparound plain and can move in all directions within it. They can >breed if theyre adjacent to another bug , can try to kill the other bug or they >can bud asexually if theyre alone. They can also go to sleep to save energy. >At random points along the plain is food to keep them alive and all their >possible actions are preprogrammed but the chance of them doing any of the >actions is controlled by their genes which are a list of probabilities. So far >things look promising even if the ultimate potential is somewhat limited. > >NJR > I've cross posted this to comp.ai.alife because I think people there might be interested. There could be some interesting cross-fertilization between these groups at the moment, as the most interesting discussion on rec.games.corewar is very much to do with artificial life. Let's see if we can give each other some ideas! Francis. From: Ross Morgan-Linial Subject: Re: Pro hill Date: 1996/08/27 Message-ID: #1/1 references: <960825212154_102741.2022_GHT140-1@CompuServe.COM> newsgroups: rec.games.corewar On 25 Aug 1996, Justin Kao wrote: // Can anyone help me with getting onto the -94 hill? Both my coreclears which // do reasonably well on Wilkies and the beginner hill did _very_ badly when I // sent them to the pro hill. When it was working that is... :( // // Anyway, just wondering there seems to be other things important to doing well // on the -94 hill that aren't important on Wilkies and the beginner hill. // // // Justin The reason coreclears are doing so well on the beginner hill is the enormous amount of papers there. There is very little paper on the pro hill, and almost all of those are pspaced with something else. So it will be very difficult to get a coreclear on the pro hill. Try a bomber/qscan, or mabie a pspacer. The moral: the demographics of a hill contributes to your score just as much as the quality of your program. ------ Ross Morgan-Linial * rmorganl@fhcrc.org Any man who goes to a psychiatrist ought to have his head examined. - Samuel Goldwyn From: neil@ogham.demon.co.uk Subject: Re: Artificial Life, Redcode, & Tierra Date: 1996/08/27 Message-ID: <841149860.10179.0@ogham.demon.co.uk>#1/1 newsgroups: rec.games.corewar Robert Macrae wrote: >neil@ogham.demon.co.uk wrote: > >>... A far simpler method to use is the probabilities method where the >> programs "genes" are a list of *probabilities* of a particular piece of >> prewritten code or action being carried out per tick of the overall >> control program... This could probably be mapped onto a corewars >> scenario somehow... > >Sounds like an interesting way to smooth a search-space which has sharp >minima, but don't you end up with an enormous extra computional burden? I Errr ... you've lost me there... >think you need to calculate a large number of fitnesses _per_individual_ >to integrate over the probability space; does this gain anything compared >to just having a larger population? Apologies beforehand as this is going somewhat off-topic... I'm currently writing a simple alife/GA program based on something I saw on TV years back which uses probabilities to control some little bugs which exist on a 2-D wraparound plain and can move in all directions within it. They can breed if theyre adjacent to another bug , can try to kill the other bug or they can bud asexually if theyre alone. They can also go to sleep to save energy. At random points along the plain is food to keep them alive and all their possible actions are preprogrammed but the chance of them doing any of the actions is controlled by their genes which are a list of probabilities. So far things look promising even if the ultimate potential is somewhat limited. NJR From: sieben@imap1.asu.edu Subject: pmars win95 Date: 1996/08/27 Message-ID: <4vtjtv$518@news.asu.edu>#1/1 newsgroups: rec.games.corewar I'm trying to port pmarsv to win95. (Un)fortunately neither Stefan nor I have win95 installed at home so don't expect quick results. I need somebody with win95 installed who have any experience with djgpp2 and grx2. Right now pmars compiles with djgpp2 and grx2 and it even runs (well almost) under the dos extender but it seems incredibly bad under win95. Nandor. From: jklewis@stimpy.us.itd.umich.edu (John K. Lewis) Subject: Re: Tierra, Redcode, toleration and mutation Date: 1996/08/28 Message-ID: <50232g$f3m@lastactionhero.rs.itd.umich.edu>#1/1 references: <840378757.19580.0@ogham.demon.co.uk> <4v7hv6$h91@nw101.infi.net> <321EE1F7.42C4@mail.tds.net> <32247905.5557641@news.demon.co.uk> newsgroups: comp.ai.alife,rec.games.corewar Francis Irving (francis.irving@vegauk.co.uk) wrote: : Just what does make an instruction set more tolerant of mutants, and : more likely to evolve? Restricting the command set to only "useful" commands. There are a large number of command which serve no purpose in the Redcode search space. : Tierra (at least a few years ago, I'd be interested in someone telling : us about more recent versions), used several techniques. Two of these : are: : : 1. Templates for jump instructions. Instead of jumping by a number, : you jump to a "label" (or template) which is basically a sequence of : marking instructions. This allows new instructions to be inserted, or : duff ones deleted without the jump instruction having to be updated as : well. New routines to jump to sensible places in old routines, much : more easily. I've simulated something like this only in the initial creating stage. I want to work more on this later, but I have my hands full with just the speciation I am doing now. : 2. Not having a comprehensive set of instructions. It effectively : only had the instructions required to write the original (primordial) : program! This was silly from a human point of view, and annoying to : write a new program yourself, but it lead to interesting competition. Agreed. It's hard to simulate this in the current release of Redcode. : Can anyone think of any other ways to do this? What techniques have : been used, and what programs were they in? I am using Perl to create random programs that fight in a GA system. [ john k. lewis ] [ jklewis@umich.edu ] [ 7-3748 ] [ sig.virus v1.4 ] From: Ross Morgan-Linial Subject: Re: Artificial Life, Redcode, & Tierra Date: 1996/08/28 Message-ID: #1/1 references: <841149860.10179.0@ogham.demon.co.uk> <32232e5f.6615716@news.demon.co.uk> newsgroups: rec.games.corewar On Tue, 27 Aug 1996, Francis Irving wrote: // I've cross posted this to comp.ai.alife because I think people there // might be interested. // // There could be some interesting cross-fertilization between these // groups at the moment, as the most interesting discussion on // rec.games.corewar is very much to do with artificial life. // // Let's see if we can give each other some ideas! // // Francis. And I've crossposted a similar thread there, over here :-) ------ Ross Morgan-Linial * rmorganl@fhcrc.org Any man who goes to a psychiatrist ought to have his head examined. - Samuel Goldwyn From: neil@ogham.demon.co.uk Subject: Re: Artificial Life, Redcode, & Tierra Date: 1996/08/28 Message-ID: <841247160.25197.0@wsoltd4.demon.co.uk>#1/1 newsgroups: rec.games.corewar Justin Kao <102741.2022@CompuServe.COM> wrote: >>TV years back which uses probabilities to control some little bugs which exist>>on a 2-D wraparound plain and can move in all directions within it. They can >>... > >I think Dewdney wrote an article about that too... :-) Except I don't remember>any sleeping bugs or muderous bugs in his version... Yeah , he could well have done. He seems to have been an inspiration for a lot of things related to alife and corewars naturally. Whats he up to these days? Anyone know? NJR From: jklewis@stimpy.us.itd.umich.edu (John K. Lewis) Subject: Re: Hills working? Date: 1996/08/28 Message-ID: <50214p$f3m@lastactionhero.rs.itd.umich.edu>#1/1 references: <960828024556_102741.2022_GHT144-1@CompuServe.COM> newsgroups: rec.games.corewar I'll check into the problem. I don't think it should be down, but then that's no guarantee. John - Justin Kao (102741.2022@CompuServe.COM) wrote: : Does anybody know when the Pizza hills will be working? Also, is the : Limited Process hill down too? I sent a program there about 2 hours : ago.... : : : Justin -- [ john k. lewis ] [ jklewis@umich.edu ] [ 7-3748 ] [ sig.virus v1.4 ] From: joshua Subject: Re: Possible new FAQ... comments needed. Date: 1996/08/28 Message-ID: <50115o$t4q@zoom2.telepath.com>#1/1 references: <4vkjhe$5qa@lastactionhero.rs.itd.umich.edu> newsgroups: rec.games.corewar Hi. The new FAQ looks good, but you might want to include some info on Pspace and brainwashing in the glossary. "Possessions" is spelled wrong in the first section. God knows how far back that error goes joshua From: Ross Morgan-Linial Subject: Re: Tierra, Redcode, toleration and mutation Date: 1996/08/28 Message-ID: #1/1 newsgroups: comp.ai.alife,rec.games.corewar Just a prefix: The diffrence between what is trying to be done with redcode, and tierra, is that for tierra programs the evaluation function and the mutation/replication engine are identical. For redcode, you want to use any form of GA that will create redcode, and then test this redcode to determine fitness. The eventual goal is a redcode program that will compare favorably with programs written by humans in competition. On Wed, 28 Aug 1996, Francis Irving wrote: // On Tue, 27 Aug 1996 08:45:58 -0700, Ross Morgan-Linial // wrote: // // >Well, the thread over in r.g.corewars is "Artificial Life, Redcode & // >Tierra". They're (we're) trying to figure out a good method of // >representing the redcode instruction set, to be more tolerant of mutants. // // I'm very interested in this. // // Just what does make an instruction set more tolerant of mutants, and // more likely to evolve? Anything that makes a random mutation less likely to be harmful or fatal makes the instruction set more tolerant of mutants. // // Tierra (at least a few years ago, I'd be interested in someone telling // us about more recent versions), used several techniques. Two of these // are: // // 1. Templates for jump instructions. Instead of jumping by a number, // you jump to a "label" (or template) which is basically a sequence of // marking instructions. This allows new instructions to be inserted, or // duff ones deleted without the jump instruction having to be updated as // well. New routines to jump to sensible places in old routines, much // more easily. This is a very important feature, IMHO. // // 2. Not having a comprehensive set of instructions. It effectively // only had the instructions required to write the original (primordial) // program! This was silly from a human point of view, and annoying to // write a new program yourself, but it lead to interesting competition. // The programs appeared very inventive to us because they were made in // such restrictive circumstances. I think this also increased the // chance of a useful mutation. Redcode, also, has a fairly small instruction set. A few math instructions, a few conditionals, move, and some wierd ones. It does not have the useful property of having 2^X diffrent opcodes, however. // // Can anyone think of any other ways to do this? What techniques have // been used, and what programs were they in? // // Perhaps our new version of Redcode will need to be very different, and // in turn create a whole new competition for human authors... Well, most of the point is to make programs that cope with actual redcode (which is more limited than the Tierra instruction set, BTW). My line of thought concentrates on some instruction set which is robust to mutation, and can then be "compiled" to normal redcode. ------ Ross Morgan-Linial * rmorganl@fhcrc.org Any man who goes to a psychiatrist ought to have his head examined. - Samuel Goldwyn From: francis.irving@vegauk.co.uk (Francis Irving) Subject: Mirror sights? Date: 1996/08/28 Message-ID: <3224782d.5341566@news.demon.co.uk>#1/1 newsgroups: rec.games.corewar I'm having trouble accessing ftp.csua.berkeley.edu. (On a PC using Netscape, it just gives an error, using an ftp DOS ftp program I log in ok, but then ls or dir cause an invalid port error). Are there any mirror sights (preferable european?) Thanks, Francis. From: francis.irving@vegauk.co.uk (Francis Irving) Subject: Tierra, Redcode, toleration and mutation Date: 1996/08/28 Message-ID: <32247905.5557641@news.demon.co.uk>#1/1 references: <840378757.19580.0@ogham.demon.co.uk> <4v7hv6$h91@nw101.infi.net> <321EE1F7.42C4@mail.tds.net> newsgroups: comp.ai.alife,rec.games.corewar On Tue, 27 Aug 1996 08:45:58 -0700, Ross Morgan-Linial wrote: >Well, the thread over in r.g.corewars is "Artificial Life, Redcode & >Tierra". They're (we're) trying to figure out a good method of >representing the redcode instruction set, to be more tolerant of mutants. I'm very interested in this. Just what does make an instruction set more tolerant of mutants, and more likely to evolve? Tierra (at least a few years ago, I'd be interested in someone telling us about more recent versions), used several techniques. Two of these are: 1. Templates for jump instructions. Instead of jumping by a number, you jump to a "label" (or template) which is basically a sequence of marking instructions. This allows new instructions to be inserted, or duff ones deleted without the jump instruction having to be updated as well. New routines to jump to sensible places in old routines, much more easily. 2. Not having a comprehensive set of instructions. It effectively only had the instructions required to write the original (primordial) program! This was silly from a human point of view, and annoying to write a new program yourself, but it lead to interesting competition. The programs appeared very inventive to us because they were made in such restrictive circumstances. I think this also increased the chance of a useful mutation. Can anyone think of any other ways to do this? What techniques have been used, and what programs were they in? Perhaps our new version of Redcode will need to be very different, and in turn create a whole new competition for human authors... Francis. From: jjv@athena.mit.edu (Jonathan Venezian) Subject: Current RedCode Spec Date: 1996/08/29 Message-ID: <504lo6$161@senator-bedfellow.MIT.EDU>#1/1 newsgroups: rec.games.corewar -------------------- Where can I obtain a current spec for RedCode/Mars. A friend and I are currently putting together an interpreter (that should be Win16/Win32 compatible), but we're using original ('87) spec, and it looks like things have changed a lot since then. Would like to put it together so it can at least optionally configure to the current state-of-the-art. Thanx, Jonathan From: jklewis@stimpy.us.itd.umich.edu (John K. Lewis) Subject: Re: Current RedCode Spec Date: 1996/08/29 Message-ID: <504quk$ea4@lastactionhero.rs.itd.umich.edu>#1/1 references: <504lo6$161@senator-bedfellow.MIT.EDU> newsgroups: rec.games.corewar http://www.ecst.csuchico.edu/~pizza/koth/icws94.html Jonathan Venezian (jjv@athena.mit.edu) wrote: : -------------------- : Where can I obtain a current spec for RedCode/Mars. : A friend and I are currently putting together an interpreter (that should be : Win16/Win32 compatible), but we're using : original ('87) spec, and it looks like things have changed a lot since then. : Would like to put it together so it can at least optionally configure to the : current state-of-the-art. : : Thanx, : Jonathan : -- [ john k. lewis ] [ jklewis@umich.edu ] [ 7-3748 ] [ sig.virus v1.4 ] From: gwilliam@hgmp.mrc.ac.uk (Gary Williams) Subject: Re: Tierra, Redcode, toleration and mutation Date: 1996/08/29 Message-ID: <503oeo$2uc@mercury.hgmp.mrc.ac.uk> references: <840378757.19580.0@ogham.demon.co.uk> <321EE1F7.42C4@mail.tds.net> <32247905.5557641@news.demon.co.uk> newsgroups: comp.ai.alife,rec.games.corewar In article <32247905.5557641@news.demon.co.uk>, Francis Irving wrote: >On Tue, 27 Aug 1996 08:45:58 -0700, Ross Morgan-Linial > wrote: > >>Well, the thread over in r.g.corewars is "Artificial Life, Redcode & >>Tierra". They're (we're) trying to figure out a good method of >>representing the redcode instruction set, to be more tolerant of mutants. > >I'm very interested in this. > >Just what does make an instruction set more tolerant of mutants, and >more likely to evolve? Carbon life does this in several ways: Tolerance of mutations ---------------------- This is partially done by redundancy: - three bases code for one amino acid, there are 64 combinations of the four standard bases coding for 20 amino acids (plus some 'control' combinations), thus there are several combinations of bases for each possible amino acid - why not try adding parity bits to multi-byte words to recover damaged codes. - on a genome level, there are sometimes duplicates of vital gene so that damage to one copy can be tolerated, but I guess that this mechanism will emerge from any evolving genome, be it Silicon, Carbon or whatever. - diploidy. A fancy term for having two of every chromosome. This is fairly essential for sex (see below) and it has the advantage that two variants of a gene can coexist, so even if one is non-functional, the gene works (almost) normally. It is difficult to think of a good way of incorporating two instructions for everything into redcode, but someone may come up with an idea. Likely to evolve ---------------- There are still furious arguments raging in biology on the precise details of the mechanisms by which evolution proceeds. It is clear however that swapping parts of genomic material is performed by pretty well every species looked at (yes there are a few exceptions, but these may not be long-lived species). Sex is the mechanism by which multi-celled organisms do this and it works very nicely :-) This tends to assume that it is difficult to get hold of genomic material and that specific mechanisms must be evolved to exchange genetic material. This is not the case in Tierra or Redcode where the genetic material is very (too?) accessible. Possibly the best way for the rate of evolution to be increased is to make the environment large enough for a huge number of organisms to coexist, varied enough for local variants to establish themselves and have islands which are periodically isolated from the main environment for hundreds of generations at a time where speciation can occur. But most of all, you require TIME. >Tierra (at least a few years ago, I'd be interested in someone telling >us about more recent versions), used several techniques. Two of these >are: > >1. Templates for jump instructions. Instead of jumping by a number, >you jump to a "label" (or template) which is basically a sequence of >marking instructions. This allows new instructions to be inserted, or >duff ones deleted without the jump instruction having to be updated as >well. New routines to jump to sensible places in old routines, much >more easily. > >2. Not having a comprehensive set of instructions. It effectively >only had the instructions required to write the original (primordial) >program! This was silly from a human point of view, and annoying to >write a new program yourself, but it lead to interesting competition. >The programs appeared very inventive to us because they were made in >such restrictive circumstances. I think this also increased the >chance of a useful mutation. > >Can anyone think of any other ways to do this? What techniques have >been used, and what programs were they in? > >Perhaps our new version of Redcode will need to be very different, and >in turn create a whole new competition for human authors... > >Francis. Have you ever though of creating a 2 (or 3) dimensional environment? I played around with idea once, but visualisation is a big problem. Gary Williams http://www.hgmp.mrc.ac.uk/ Email: G.Williams@hgmp.mrc.ac.uk Tel: +44 1223 494522 Computing Services, MRC HGMP Resource Centre, Hinxton, Cambridge, CB10 1SB, UK From: PBMNET Subject: WANTED: Moderators, Hosts, PBM/PBeM Web Sites. Date: 1996/08/29 Message-ID: #1/1 newsgroups: rec.games.corewar *** COMING SOON: _HUGE_ NEW 'NET GAMING' WEB SITE! *** Maintained _by_ internet gamers _for_ internet gamers. We're nearing completion on setting up a new 'net gaming' Web site aiming to cover _all_ aspects of the hobby, with contact info on all moderators / hosts / games and providing links to every other related site in the world that we can possibly trace. And much, much more! Whether you moderate commercial PBM games (Email and/or 'Snailmail'), host shareware games, run hobby games of any kind, or simply maintain a PBM-related Web site just for the fun of it, then please send us your email address. If you're a player of any games then please send us the email addresses of every company / individual you play with - just in case they lurk here only rarely or miss this note themselves! Don't worry about any possible duplicates - our growing database automatically disgards such. When this huge new site is more or less ready, in a week or so, we'll contact all game-running and/or site-maintaining companies & individuals known to us at that time, for a sneak preview. They will be able to register and describe their contact details, games & Web sites for inclusion on our pages, either on-line or by downloading our simple software designed for this purpose. Shortly after that we'll announce our Web URL in this and other related newsgroups. Although designed for Netscape v2.0+ & compatible browsers (lots of table page formatting, etc.) there will also be a 'crappy' version of all pages available for users of such as Compu$erve Mosaic and other naff web browsers, so nobody should feel left out! _Please_ help us to make this a useful, interesting & informative site for the net games hobby as a whole. Please mail your list of known addresses to: webmaster@gamenet.demon.co.uk - not to my own mailbox! Many thanks, Dave. -- PBMNET - The World Of Internet Gaming. David Wells From: Tim Chapman Subject: Re: Artificial Life, Redcode, & Tierra Date: 1996/08/30 Message-ID: #1/1 newsgroups: rec.games.corewar On Tue, 27 Aug 1996, David A Johnston wrote: > I've always found that one of the great beauties and advantages of > evolution is its simplicity. The thing is that in real life, it's not > some outside force that's mutating genes, but rather the genes > themselves. So why not build programs that modify themselves, according > to their own algorithm? This is the sort of thing Tierra does, as near > as I can tell. This allows the mutation algorithm to change as well, to > become better suited to its environment. > I don't think that Tierra allows the programs themselves to modify the mutation algorithms. The mutations occur as a chance factor in every instruction which is copied. However, this is still an interesting idea. Why not evolve a system to evolve corewar programs? This approach would automatically evolve to perform any necessary techniques to smooth the genetic space. I suspect, however, that the problem would be in evolving the system itself... Tim Chapman From: us039143@interramp.com Subject: Your signature can be a TrueType font! 26220 Date: 1996/08/31 Message-ID: <199608311801.OAA06393@smtp2.interramp.com>#1/1 newsgroups: rec.games.corewar S I G N A T U R E F O N T S Turn your Signature into a TrueType font and say good-bye to cutting and pasting or importing from outside files forever. Now you can access your signature right from your font menu. It's easy and it's fast. In the past you had to import a previously drawn or scanned graphic that used not only a tremendous amount of space and time to display - but it also took forever to print. Well, not anymore. With the Victory Press "Signature" Font, you just click on your font menu for your signature, and presto! Your selection appears in a snap as a TrueType font in your document, fully scaleable to any size. Here is what David from San Jose had to say about the Victory Press Signature font... "Thank you for the quality job that you have done. Also, I found the installation and use of the font to be explained in such a way that even a novice, such as myself, was able to accomplish it successfully." ... Signature Fonts are priced at only $28.95 per signature. ============================================================================ O R D E R F O R M ============================================================================ VICTORY PRESS 1119 S. Mission Road Fallbrook, CA 92028-3225 SIGNATURE INSTRUCTIONS - Following these instructions will produce the best possible results. Use a black "Uni-ball" pen. This pen produces the best results. Practice writing your signature pressing firmly to get a dark, consistent signature. When finished practicing, please sign twice in the area below. Keep your signature between the lines. Please DO NOT let your signature touch the edges of the box. Fill out the order form. Mail this entire form with advanced payment or credit card information to the address below. Be careful not to fold the paper where your signature is. Once your signature is converted to a TrueType font, we'll send it back on diskette, with easy installation instructions. STYLE INFORMATION: Please send me my signature as a: [ ] TrueType Signature Font $28.95 [ ] For an additional $9.95 we will create a separate character within your font of your first name only, for times that you might want a more personal signature. I will be using my font on a: [ ] PC [ ] Mac [ ] Both PC and Mac for an additional $14.95 Please name your custom Signature font:_________________________ SIGNATURE AREA: Please Sign twice. ==================================================== Signature 1. | | | | | | | | | | | | | | | | | ==================================================== Signature 2. | | | | | | | | | | | | | | | | | -------------------------------------------------------------------- Y E S: Please send me my signature as a TrueType font. I understand that if my signature doesn't work to my satisfaction, I may return everything for a full refund. Name:______________________________________________________ Company:___________________________________________________ Address:_____________________________________________________ City:________________________________________________________ State:________________ Zip_________________________ Phone:_______________________________________________________ Fax:__________________________________________________________ Email:________________________________________________________ METHOD OF PAYMENT: [ ] My check is enclosed. Please charge my: [ ] VISA [ ] MasterCard [ ] American Express Exp. Date___________________________ Card No:______________________________________________________ Signature:______________________________________________________ PLEASE ALLOW THREE WEEKS TO CREATE AND SHIP YOUR FONT. [ ] RUSH!! We can create your signature font within 2 days and ship it to you via 3 day air letter for an additional $25.00. Total amount of sale, if you are in CA please include 7% sales tax. $______________________________ S E N D T O : VICTORY PRESS 1119 S. Mission Rd. Fallbrook, CA 92028-3225 [form #G08306] From: charles@altair.krl.caltech.edu (Charles Ofria) Subject: Re: Tierra, Redcode, toleration and mutation Date: 1996/08/31 Message-ID: <50a197$dhp@gap.cco.caltech.edu>#1/1 references: <840378757.19580.0@ogham.demon.co.uk> <321EE1F7.42C4@mail.tds.net> <32247905.5557641@news.demon.co.uk> newsgroups: comp.ai.alife,rec.games.corewar In article <32247905.5557641@news.demon.co.uk>, Francis Irving wrote: >Just what does make an instruction set more tolerant of mutants, and >more likely to evolve? > >Tierra (at least a few years ago, I'd be interested in someone telling >us about more recent versions), used several techniques. Two of these >are: > >1. Templates for jump instructions. Instead of jumping by a number, [munch] This, I believe, is a real key to the instruction set success. I wonder if anyone has done any tests with tierra, using an instruction set which does _not_ have templates. We also use a similar template structure in Avida. >2. Not having a comprehensive set of instructions. It effectively >only had the instructions required to write the original (primordial) >program! This was silly from a human point of view, and annoying to >write a new program yourself, but it lead to interesting competition. >The programs appeared very inventive to us because they were made in >such restrictive circumstances. I think this also increased the >chance of a useful mutation. I beleive certain later versions of the instruction set were made far more complete, and yet equally effective. The key thing here is to have a reasonably limited number of instructions which have all the power needed to reproduce (without being _too_ low level, and hence potentially awkward to do things.) >Can anyone think of any other ways to do this? What techniques have >been used, and what programs were they in? I'd add on a: 3. Allow many combinations of instructions to work (preferably in a logical manner so that a human can decyrpt it!) I think this is one mistake Tierra made; there were many possible instructions combinations which would cause errors, and many others which had no-effect and hence dead code. The key thing here is that it has to be meaningful, and to a good extent redundent (ie. it could have been done in other ways.) If every pair of instructions does something totally unique, then you might as well just have N^2 of them rather than N. To elaborate: In Avida we tried to take more advantage of nops in places other than just for templates. We use three nops rather than the two from Tierra; nop-A, nop-B, and nop-C. We also use only three registers in the CPU, so if an register manipulating instruction is followed by a nop, it effects the corrisponding CPU. All such instructions have a default register they work on. Thus: shift-l nop-C would shift the CX register left. By default, shift-l works on BX. Without this feature, the BX register would have to be put on the stack, the CX would then be put there and poped back out into BX, shifted, moved back over, and finally BC would be restored. Looking like: push-b push-c pop-b shift-l posh-b pop-c pop-b Dunno... it seems to work. :-) Any other ideas for instruction sets out there? --- Charles -- "Nothing will benefit human health and Charles Ofria increase the chances for survival of charles@krl.caltech.edu life on Earth as much as the evolution http://www.krl.caltech.edu/~charles to a vegetarian diet" -Albert Einstein The Avida artificial life group