March 16, 1994 Issue #4
______________________________________________________________________________
This newletter covers the current status of the ICWS '94 Draft hills,
and also attempts to keep up with the latest ideas in how the new standard
will affect corewars in general. I hope you enjoy it!
If you are unfamiliar with the '94 draft standard, you can learn more about
it by reading the FAQ for this newsgroup. In addition, the program pMARS
includes a highly recommended tutorial on the new standard. Feel free
to send me e-mail if you have any difficulty finding either of them, if you
need to have a corewar item mailed to you, or if you have any other questions.
The FAQ is available through anonymous FTP to rtfm.mit.edu, as
/pub/usenet/news.answers/games/corewar-faq.Z
______________________________________________________________________________
The ICWS '94 Draft Hill:
Core size: 8000 instrucitons
Max processes: 8000 per program
Duration: After 80,000 cycles, a tie is declared.
Max entry length: 100 instructions
The current ICWS '94 Draft hill:
# %W/ %L/ %T Name Author Score Age
1 46/ 31/ 23 Killer instinct Anders Ivner 162 9
2 42/ 23/ 34 NC II Wayne Sheppard 162 64
3 41/ 25/ 35 Sphinx v5.1 W. Mintardjo 157 67
4 37/ 22/ 42 ttti94 nandor sieben 152 15
5 46/ 42/ 12 Fire Storm v1.1 W. Mintardjo 151 70
6 36/ 22/ 43 ttti nandor sieben 150 20
7 38/ 26/ 36 JustTakingALookSee J.Layland 150 63
8 43/ 41/ 16 Sylvester v1.0 Brant D. Thomsen 145 46
9 42/ 40/ 17 Request v2.0 Brant D. Thomsen 144 2
10 35/ 26/ 39 Snake Wayne Sheppard 144 19
11 41/ 39/ 20 Christopher Steven Morrell 143 8
12 41/ 40/ 19 Fast Food v2.1 Brant D. Thomsen 142 22
13 41/ 42/ 16 Ntttgtstitd Simon Hovell 141 10
14 43/ 45/ 13 Rave 4 Stefan Strack 141 3
15 41/ 41/ 18 Beholder's Eye v1.7 W. Mintardjo 140 76
16 43/ 46/ 11 Rave Stefan Strack 140 47
17 41/ 43/ 16 SJ-4 J.Layland 140 13
18 40/ 40/ 21 tiny J.Layland 140 44
19 42/ 46/ 12 Testing an Idea Brant D. Thomsen 138 1
20 42/ 48/ 11 Impurge 94 Fredrik Ohrstrom 136 6
The '94 draft hill seems to be getting quite vicious lately. There were
several attempts at the hill, but not very many made it.
(The program "Testing an Idea" is discussed in this issue's hint section.)
______________________________________________________________________________
th ICWS '94 Draft Experimental Hill:
Core size: 55,440 instructions
Max processes: 10,000 per program
Duration: After 500,000 cycles, a tie is declared.
Max entry length: 200 instructions
The current ICWS '94 Experimental hill:
# %W/ %L/ %T Name Author Score Age
1 53/ 12/ 35 BigImp Alex MacAulay 194 25
2 52/ 17/ 30 Imperfection v1.0 X Michael Constant 187 21
3 60/ 34/ 6 Rave 3 (55440) Stefan Strack 185 36
4 42/ 13/ 45 Skimp 127 Jay Han 171 6
5 54/ 42/ 4 No Ties Allowed Wayne Sheppard 166 41
6 51/ 38/ 10 Dagger v6.0 X Michael Constant 164 24
7 41/ 17/ 42 BigImps James Layland 164 44
8 49/ 39/ 12 Sunburst 33 Jay Han 159 14
9 44/ 31/ 25 CG-X IV Brant D. Thomsen 157 35
10 49/ 42/ 10 BS J.Layland 156 43
11 41/ 34/ 25 Iron Gate Wayne Sheppard 148 40
12 35/ 26/ 39 FatImp Jay Han 144 1
13 40/ 50/ 10 Silly 2 James Ojaste 130 7
14 41/ 54/ 5 Silly James Ojaste 129 9
15 33/ 46/ 21 testing testing Fredrik Ohrstrom 121 31
16 32/ 46/ 22 Crimp Jay Han 118 2
17 34/ 53/ 13 VJX-2a James Ojaste 115 28
18 28/ 42/ 31 Bloom Jay Han 114 12
19 30/ 50/ 20 Surprise7b James Ojaste 109 10
20 32/ 59/ 8 VJX-2 James Ojaste 105 29
WOW! Due largely to the efforts of Jay Han and James Ojaste, the '94
experimental hill has really changed over the last couple of weeks. So far,
it looks like imp-spiral/stone combinations and scanners are dominating
the hill. (Has anyone out there tried a paper or vampiric program? I'd
be curious to know how it does.)
______________________________________________________________________________
HINTS and HELPS:
One of the most irritating things in corewars is handling those programs
that refuse to die. You know what I mean: your scanner/bomber/vampire
has stunned the opponent; and then, suddenly, the enemy comes to life in
the middle of your core-clear and finishes you off.
The '88 solution to this problem has been the two-pass core clear. (I have
no idea who was the first person to use this technique, but it is now quite
common.) During the first pass of the core-clearing loop, the code fills
the core with "SPL 0" statements; during the second pass, the code overwrites
the core with "DAT" statements. The "SPL 0" instructions greatly increase
the odds that the program is no longer a threat, and the "DAT" insructions
are to kill your opponent off altogether. This method is very efficient,
but it has some disadvantages as well: multiple-pass core-clears can be
hard to set up, and they are often disabled by fast bombers.
A similar method that can be used with the '94 standard is to use your
core-clearing routine to "confuse" the core instead. Take a look at the
following code:
clear spl.B #0, <-20 ; Equivalent to: SPL.B 0, <-20
mov.I 2, <-11 ; Overwrite the core
confuse djn.F -1, >1 ; Confuse the core
dat.F <-21, #10 ; Give a pointer to work with
The first two lines are the '94 equivalent of a standard core-clear.
The "SPL 0" line generates processes, which the "MOV" uses to fill the
core with "DAT" instructions.
The last two lines are used to "confuse" the core. The "DJN" instruction
will decrement both the A and B-field values of the instructions as it
proceeds forward through the core. This decrementing is usually enough to
keep any program it meets from working correctly, so the
standard part of the core-clear (which is working its way backwards
through the core) will have no problem completely killing the opponent when
it gets to it. Since the "MOV" instruction in the core-clear gets the
processes created by the "SPL 0" before the "DJN" instruction does, it will
always complete first -- so the confusion will never reach the core-clear
itself.
This technique has several advantages over a two-pass core-clear.
In addition to being at least twice as fast, it is also easy to implement
and fairly rugged. In fact, the "confuse" line can be bombed by a "DAT"
statement and the core-clear will still work.
There are several attributes of using this core-clearing method that cause
it to work well against imp-spirals as well. The multiple processes
running during the clear will give your program a tie if the core-clear
is over-run before it has completed, and the imp-gate at the end will
(usually) stop imp-spirals if any remain when the core-clear is completed.
An important thing to notice is that the location pointed to by the
"confuse" line has a positive value. This is because the "confusion" will
not work correctly if this value is zero. (The decrementing and incrementing
cancel each other out.)
As a final test to see how well this idea works, I added a "confusion"
core-clear to the program "Rave 3" (from the last issue) and submitted it
to the hill to see how it does. It is under the name "Testing an Idea".
It looks as if there are currently so many scanners on the hill that the
adding of the two extra lines turned into a disadvantage. (Perhaps I should
have saved this hint for a later issue instead! :-)
______________________________________________________________________________
Looking to the Future:
The lastest draft of the standard has been on soda.berkeley.edu for over
a month now (as /pub/corewar/documents/icws94.0202.Z). Take a look at it
and let the newsgroup know what you think. There are some interesting
additions to the former '94 draft standard, so it's worth your effort
to get a copy and study it.
Also, please submit your programs to the '94 hills. We'd love to have your
best KOTH warrior on the standard '94 hill, even if it is still '88
compliant.
If you have any comments or questions about the '94 hills or the '94
standard that you think might be of general interest, please let me know.
Good luck, and happy computing!
______________________________________________________________________________
Brant D. Thomsen, Editor Snail mail: 1197 East 6290 South
(bdthomse@peruvian.cs.utah.edu) Salt Lake City, UT 84121
University of Utah U.S.A.
--
Brant D. Thomsen The teaching of BASIC in schools
(bdthomse@peruvian.cs.utah.edu) should be considered a criminal act.
University of Utah - Dijkstra
|
