Archived from groups: rec.games.corewar (More info?)
....................................................................
.. .
.. .
.. | \ | | | | .
.. | | ) | | | | | .
.. | // \/ ` |/ / \ / ` |/ \ ' / | .
.. | | \ \ / ( | | ( | ( ) | ( | | / | \ \ .
.. | | \ \ |\ , |\ \ / \ , |\ | | | / .
.. .
.. .
.. | | .
.. | | .
.. | | ' / \ ' \| / | | | .
.. | | | | | / | | |/ /| | | | .
.. | | | | \ | | | / |\ , | .
.. / | .
.. | / .
.. .
.. .
.. | \ /| .
.. / / / | .
.. / / / | .
.. / | | .
.. .
....................................................................
..............................
. .
. Core Shrinking Knockout .
. .
..............................
It's time for the next round of the Redcoder's Frenzy!
This is the 24th round of the ongoing corewar tournament. Detailed
information is available on Fizmo's Corewar Info Page:
http://www.corewar.info/tournament/cwt.htm
The Core Shrinking Knockout Round homepage is:
http://www.corewar.info/tournament/24.htm
....................................................................
.. .
.. | | .
.. | ' | || | / - | -< .
.. | | \ , | \ / / .
.. .
....................................................................
Your duel-warriors use to fight in a 8,000 core against their
opponents, that means 4,000 cells per warrior; this is why they
feel uncomfortable when fighting in a multi-warrior arena! Time has
come to give your warriors the space they need: let them fight in a
core providing 4,000 cells per warrior! There is only one drawback:
your warriors will not know how many challengers there are, and so
they will not know which will be the actual core size; will they be
smart enough to survive the challenge?
Actually, this Redcoders Frenzy Round realizes the same rules of
IRC#35 except in a "standard" core specification. This means that
this will not be a single challenge round as usual; instead, each
warrior will fight in a sequence of challenges, as long as it is
eligible to pass to next challenge.
Each challenge is a multi-warrior run where all the warriors
compete at once; the core size will be 4,000 times the count of
warriors in the current challenge, and the other parameters will be
adjusted proportionally. Let W be the count of warriors in the
current challenge, the arena will then use these settings:
Core size = 4,000 x W
Max cycles = 40,000 x W
Max processes = 4,000 x W
Max length = 100 (fixed)
Min distance = 100 (fixed)
P-space size = 250 x W
Number of rounds = 5 x 200 (5 fights of 200 rounds each)
Use of CORESIZE, MAXCYCLES, MAXPROCESSES, PSPACESIZE and any other
mean to statically compute the core size is forbidden; the warrior
code must dynamically adapt to the actual core size or be
independent of the core size. This includes using values greater
than 4000 or less than -3999 in your code if this will do; in few
words, the compiled warrior must be the same in all the challenges,
once that values greater than CORESIZE/2 have been converted to
negative numbers. Note that this is the standard output when you
run pmars.
P-space and PIN are allowed, so you can make a wise use of
persistent memory and of handshake.
Challenge scoring: A warrior gets 1 point for each round it was the
only survivor (same rule as standard multi-hill at KOTH).
Tie breaking: if two or more warriors happen to score the same,
they will be sorted according to how many times they was one
survivor out of 2, and so on; if the tie persists, the results of
the previous challenge(s) will be considered.
Passing to next challenge: The warrior that scores least in the
current challenge is knocked out, and all the other warriors will
pass to next challenge; the arena of next challenge will then be
adapted to the new number of warriors. This means that as the
challenges proceed the core will shrink up to the standard size of
8,000 cells, until the last two survivor warriors will end up
running a standard duel in a standard core.
Frenzy percent: This is the hardest thing to decide! I came up with
this solution: say p is the score of the first warrior in the
current challenge, q is the score of the knocked out warrior in the
current challenge, and S is the Frenzy percent of the knocked out
warrior computed for the previous challenge. The knocked out
warrior in the current challenge should get of course more than S
Frenzy percent and less than 100 Frenzy percent; this can be
achieved by adding S to (q / p) x (100 - S). By the way I think
about introducing some parameter f and replacing q / p with (q + f)
/ (p + f) in order to not having too low Frenzy percents for the
last warriors and too close Frenzy percents for the first warriors;
this f parameter will be high in the first challenge and will
decrease down to 1 / 3 of the ties in the last challenge.
Hints:
- The IRC#35 is of course a starting point, because it has the same
rules as this RFT#24 except for the tiny core specification; you
can even see which will be the pmars commands performed on the
entries (well, just add some 0's around) so you can get a real grip
on how this Frenzy Round works.
- Remember that location #0 of P-space holds -1 in the first round;
it holds 0 if the warrior died in the previous round; it holds 1 if
the warrior was the only survivor of the previous round; in the
other cases, it holds the count of the warriors that survived the
previous round, which can be greater than 2. This will affect P^x
switchers.
- You can guess the actual size of the core in your first round of
each fight and use the result in subsequent rounds by storing the
value in your P-space; the handshaking friend can help computation
or just use the result as far as both warriors are not knocked out.
- You can ;assert (CORESIZE % 4000 == 0) && (CORESIZE >= 8000) if
you want, and do whatever you like with the other redcode
constants; as far as the warrior always compiles, and the compiled
code always looks the same in all the possible CORESIZE contexts,
your entry will not be rejected.
....................................................................
.. .
.. | | | | ( ) .
.. / ` / - ) ` / ` | | | ' \/ - ) .
.. \ , \ \ , \ , | | | || \ | .
.. .
....................................................................
23:59 (CEST) September 30, 2005
--------------------------------------------------------------
Please send your entries to LAchi
(achillu[at]tin.it)
Use
RFT24 ENTRY
as the subject line (even if they are 2 entries)
--------------------------------------------------------------
Each participant can send up to 2 warriors as usual.
Good luck, and may the core be with you!
....................................................................
.. .
.. .
.. | \ | | | | .
.. | | ) | | | | | .
.. | // \/ ` |/ / \ / ` |/ \ ' / | .
.. | | \ \ / ( | | ( | ( ) | ( | | / | \ \ .
.. | | \ \ |\ , |\ \ / \ , |\ | | | / .
.. .
.. .
.. | | .
.. | | .
.. | | ' / \ ' \| / | | | .
.. | | | | | / | | |/ /| | | | .
.. | | | | \ | | | / |\ , | .
.. / | .
.. | / .
.. .
.. .
.. | \ /| .
.. / / / | .
.. / / / | .
.. / | | .
.. .
....................................................................
..............................
. .
. Core Shrinking Knockout .
. .
..............................
It's time for the next round of the Redcoder's Frenzy!
This is the 24th round of the ongoing corewar tournament. Detailed
information is available on Fizmo's Corewar Info Page:
http://www.corewar.info/tournament/cwt.htm
The Core Shrinking Knockout Round homepage is:
http://www.corewar.info/tournament/24.htm
....................................................................
.. .
.. | | .
.. | ' | || | / - | -< .
.. | | \ , | \ / / .
.. .
....................................................................
Your duel-warriors use to fight in a 8,000 core against their
opponents, that means 4,000 cells per warrior; this is why they
feel uncomfortable when fighting in a multi-warrior arena! Time has
come to give your warriors the space they need: let them fight in a
core providing 4,000 cells per warrior! There is only one drawback:
your warriors will not know how many challengers there are, and so
they will not know which will be the actual core size; will they be
smart enough to survive the challenge?
Actually, this Redcoders Frenzy Round realizes the same rules of
IRC#35 except in a "standard" core specification. This means that
this will not be a single challenge round as usual; instead, each
warrior will fight in a sequence of challenges, as long as it is
eligible to pass to next challenge.
Each challenge is a multi-warrior run where all the warriors
compete at once; the core size will be 4,000 times the count of
warriors in the current challenge, and the other parameters will be
adjusted proportionally. Let W be the count of warriors in the
current challenge, the arena will then use these settings:
Core size = 4,000 x W
Max cycles = 40,000 x W
Max processes = 4,000 x W
Max length = 100 (fixed)
Min distance = 100 (fixed)
P-space size = 250 x W
Number of rounds = 5 x 200 (5 fights of 200 rounds each)
Use of CORESIZE, MAXCYCLES, MAXPROCESSES, PSPACESIZE and any other
mean to statically compute the core size is forbidden; the warrior
code must dynamically adapt to the actual core size or be
independent of the core size. This includes using values greater
than 4000 or less than -3999 in your code if this will do; in few
words, the compiled warrior must be the same in all the challenges,
once that values greater than CORESIZE/2 have been converted to
negative numbers. Note that this is the standard output when you
run pmars.
P-space and PIN are allowed, so you can make a wise use of
persistent memory and of handshake.
Challenge scoring: A warrior gets 1 point for each round it was the
only survivor (same rule as standard multi-hill at KOTH).
Tie breaking: if two or more warriors happen to score the same,
they will be sorted according to how many times they was one
survivor out of 2, and so on; if the tie persists, the results of
the previous challenge(s) will be considered.
Passing to next challenge: The warrior that scores least in the
current challenge is knocked out, and all the other warriors will
pass to next challenge; the arena of next challenge will then be
adapted to the new number of warriors. This means that as the
challenges proceed the core will shrink up to the standard size of
8,000 cells, until the last two survivor warriors will end up
running a standard duel in a standard core.
Frenzy percent: This is the hardest thing to decide! I came up with
this solution: say p is the score of the first warrior in the
current challenge, q is the score of the knocked out warrior in the
current challenge, and S is the Frenzy percent of the knocked out
warrior computed for the previous challenge. The knocked out
warrior in the current challenge should get of course more than S
Frenzy percent and less than 100 Frenzy percent; this can be
achieved by adding S to (q / p) x (100 - S). By the way I think
about introducing some parameter f and replacing q / p with (q + f)
/ (p + f) in order to not having too low Frenzy percents for the
last warriors and too close Frenzy percents for the first warriors;
this f parameter will be high in the first challenge and will
decrease down to 1 / 3 of the ties in the last challenge.
Hints:
- The IRC#35 is of course a starting point, because it has the same
rules as this RFT#24 except for the tiny core specification; you
can even see which will be the pmars commands performed on the
entries (well, just add some 0's around) so you can get a real grip
on how this Frenzy Round works.
- Remember that location #0 of P-space holds -1 in the first round;
it holds 0 if the warrior died in the previous round; it holds 1 if
the warrior was the only survivor of the previous round; in the
other cases, it holds the count of the warriors that survived the
previous round, which can be greater than 2. This will affect P^x
switchers.
- You can guess the actual size of the core in your first round of
each fight and use the result in subsequent rounds by storing the
value in your P-space; the handshaking friend can help computation
or just use the result as far as both warriors are not knocked out.
- You can ;assert (CORESIZE % 4000 == 0) && (CORESIZE >= 8000) if
you want, and do whatever you like with the other redcode
constants; as far as the warrior always compiles, and the compiled
code always looks the same in all the possible CORESIZE contexts,
your entry will not be rejected.
....................................................................
.. .
.. | | | | ( ) .
.. / ` / - ) ` / ` | | | ' \/ - ) .
.. \ , \ \ , \ , | | | || \ | .
.. .
....................................................................
23:59 (CEST) September 30, 2005
--------------------------------------------------------------
Please send your entries to LAchi
(achillu[at]tin.it)
Use
RFT24 ENTRY
as the subject line (even if they are 2 entries)
--------------------------------------------------------------
Each participant can send up to 2 warriors as usual.
Good luck, and may the core be with you!
Facebook
Twitter
Instagram