Sign in with
Sign up | Sign in
Your question

help needed....step sizes, airbagging, optimization and my..

Last response: in Video Games
Share
Anonymous
April 28, 2004 8:54:19 AM

Archived from groups: rec.games.corewar (More info?)

Behold Assault and Battery. Submitted to 94nop, it scores a
respectable but insufficient 110.
;redcode-94nop
;name Assault and Battery v0.1
;author Andrew Hunter
;strategy stun bomber
;strategy original version
;assert CORESIZE==8000



;-----------BOMBER-----------
step equ 2223
throw top bmbBootPtr mov.i {0,#0
ptr mov.i step,@2*step
mov.i sbmbP,{ptr
sub.f incrP,ptr
start mov.i sbmbP,@ptr
mov.i }mbmbP,*ptr
jmz.a ptr, {mbmbP
tail jmp clrBP,tail+1
;------------------------------

;-----------BOMBS-------------
sbmb spl #2,#1
mbmb mov.i @0,}-1
;-----------------------------
;positioning and weird boot needed
;for successful airbag.
;-----------D-CLEAR------------
gate equ (clrB-1)
clrB incr spl #-step*2-1,<-step*2
clr mov bomb,>gate
djn.f clr,>gate
bomb dat >2667,bomb-gate+1
;------------------------------
clrPtr dat 0,clrOff+1


bomberOff equ (tail+3240)
clrOff equ (tail+2844)
bombsOff equ (tail+1372)
sbmbP equ ((bombsOff-bomberOff)+tail-(clr-sbmb))
mbmbP equ ((bombsOff-bomberOff)+tail-(clr-mbmb))
incrP equ ((clrOff-bomberOff)+tail-(bomb-clrB))
clrBP equ incrP
;----------BOOTING CODE--------
boot bombsPtr spl 1,clr+1
bombsOffPtr spl 1,bombsOff+1
;boots the Bombs.
mov <bombsPtr,<bombsOffPtr
;boots the clear.
mov {clrPtr,<clrPtr
bomberOffPtr spl 1,bomberOff+1
mov <tail,<bomberOffPtr
djn.b >bomberOffPtr, #8

;------------------------------
;TODO: add decoy/decoymaker? Q-scan?

end boot

A bunch of questions for y'all. I picked a step of 2333 cause that's
what Behomot, which I based this off, used...but I'd like to optimize
it. Dumb brute force tends to work for that kind of stuff...BUT, not
here. You see, the boot distances are placed so
a. the clear never gets hit
and b. the bombs will get hit late in the bombing cycle, in such a way
that the airbag will fall through.
(Just so you know, that's why I boot a bit of the clear along with the
bombs.
after booting, the bombs look like this:
spl #2,#1
mov.i @0,}-1
spl #3553,#3554
mov 2, >2
The idea is that late, once a good spread has been layed down, a spl
#2,#1 bomb will land on the mov half of the incendiary (mov.i @0,}-1).
When it does, the airbag will check to see if mov 2,>2 is 0, which
it's not, and will jump to clear. (As a side note, can anyone see a
way I can get that to work w/o the two stolen lines from the clear?
If I do it the same way, then the spl line which lands points to empty
core, which is of course 0. Any ideas?)

The more important reason I'm telling you this is that it prevents me
from optimizing steps, because when I change the step, I have to hand
tune the boots to work. Any ideas on that?

Oh yeah, speaking of that, anyone got a program (I hear people talking
about such things) which randomizes certain constants and then
automatically tests them against a suite of warriors? I've got a
program I was given which can randomize the constants, but then I have
to hand benchmark them which takes a LONG time.
Oh yes, and speaking of benchmarking them...I test against the
warriors in the Wilfiz suite. Is this a good test suite?


Lastly, the Q^4.5 scan... I have a copy of this, given to me in my
warrior Cacodemon by Fizmo. I was warned that moving around the "tab"
locations could mess up the scan, and I looked at the scan code, and
can't make head nor tail of it. I'd like to add the scan to Assault
and Battery, but I don't know enough about how Q^4.5 works to safely
modify it to add my warrior and boot code. Help?
Anonymous
April 28, 2004 8:33:32 PM

Archived from groups: rec.games.corewar (More info?)

> ;-----------BOMBER-----------
> step equ 2223
> throw top bmbBootPtr mov.i {0,#0

> ptr mov.i step,@2*step
> mov.i sbmbP,{ptr
> sub.f incrP,ptr
> start mov.i sbmbP,@ptr
> mov.i }mbmbP,*ptr
> jmz.a ptr, {mbmbP
> tail jmp clrBP,tail+1
> ;------------------------------

This is pretty tough to read and I'm not certain how it works, but it seems
to throw two SPL bombs and one MOV bomb in a Tornado loop? The trouble is,
with the small constants used in the bombs some bombs must be very close to
each other. This reduces effectiveness a lot. I once had a go at writing
something similar myself, and IIRC it is possible to place 2xSPL and 1xMOV
well separated, or perhaps even 1xSPL and 2xMOV. I think either should give
a major gain in efficiency, with 2xMOV the stronger against replicators.

> A bunch of questions for y'all. I picked a step of 2333 cause that's
> what Behomot, which I based this off, used...but I'd like to optimize
> it. Dumb brute force tends to work for that kind of stuff...BUT, not
> here. You see, the boot distances are placed so
> a. the clear never gets hit
> and b. the bombs will get hit late in the bombing cycle, in such a way
> that the airbag will fall through.

One brute-force approach is to test your random variants against a passive
enemy like SPL #0, 0, and retain only those that can beat it in a single
test round (or maybe beat it 5/5 rounds). The argument is that if they can
win they probably aren't crippling themselves. The method I use is:
1) Generate 200 or so random variants.
2) Create a list of their filenames and prepend with the name of the
passive enemy.
3) Submit them to MTS in a First vs All tournament with just 1 (or 5)
rounds per battle.
4) Pipe the output into a text file (or parse the score file output), keep
the variants that won and drop the rest.
5) When I have accumulated 100 or so viable warriors, start to test them
against real warriors.

Obviously the 1-round tournaments take almost no time, so provided the
process is reasonably automated it doesn't matter if you only pick up a
handful of viable warriors per batch. The reason for batches of 200 is a
vague recollection of hitting problems with MTS as the number of warriors
got very large, but you could easily try 1000 to see if it works?

Robert
Anonymous
April 28, 2004 8:57:36 PM

Archived from groups: rec.games.corewar (More info?)

"Robert Macrae" <ff95@dial.pipex.com> wrote in message news:<408fcf7d$0$10677$cc9e4d1f@news.dial.pipex.com>...

>
> This is pretty tough to read and I'm not certain how it works, but it seems
> to throw two SPL bombs and one MOV bomb in a Tornado loop? The trouble is,
> with the small constants used in the bombs some bombs must be very close to
> each other. This reduces effectiveness a lot. I once had a go at writing
> something similar myself, and IIRC it is possible to place 2xSPL and 1xMOV
> well separated, or perhaps even 1xSPL and 2xMOV. I think either should give
> a major gain in efficiency, with 2xMOV the stronger against replicators.
No, not really. What it does is drop 2xSPL and 2xMov in a 6 line
loop,based off Tornado but modified.
But whaddya mean, separated?
2223 cells (the current step) apart, we have pairs of instructions
like this:
0000 spl #2,#1
0001 mov @0,}-1
(and the same thing at 2223,2224)

Um, what's bad about that? I'm kinda confused...how do you write
incendiaries that are meant to be seperated?
I'm in the process of doing such a brute-force optimizer right now,
thanks...
Related resources
Anonymous
April 29, 2004 3:45:22 AM

Archived from groups: rec.games.corewar (More info?)

Andrew Hunter wrote:

> A bunch of questions for y'all. I picked a step of 2333 cause that's
> what Behomot, which I based this off, used...but I'd like to optimize
> it. Dumb brute force tends to work for that kind of stuff...BUT, not
> here. You see, the boot distances are placed so
> a. the clear never gets hit
> and b. the bombs will get hit late in the bombing cycle, in such a way
> that the airbag will fall through.

In situations like that you must try to link the brute forced constant to
each other that they do what you want.

For example:

loop mov.i bomb,@bomb
add.ab #step,bomb
jmp loop
bomb dat $0,$pos

If you want make this Stone killing itself after a given number of bomb you
can't pure bruteforce with step=random, pos=random, you must do somthing
like this.

time EQU 50 ; Kill itself after 50 Bombs
pos EQU #RANDOM ; First Bomb at
step EQU #RANDOM ; Stepsize

loop mov.i bomb,@bomb
add.ab #step,bomb
jmp loop
bomb dat $0,$pos-time*step

Important is the last Line. Scanner triggering with decoy work at the same
Way.


> Oh yeah, speaking of that, anyone got a program (I hear people talking
> about such things) which randomizes certain constants and then
> automatically tests them against a suite of warriors? I've got a
> program I was given which can randomize the constants, but then I have
> to hand benchmark them which takes a LONG time.
> Oh yes, and speaking of benchmarking them...I test against the
> warriors in the Wilfiz suite. Is this a good test suite?
>

Wilfiz is O.K for a quick overview of your Warriors strength. But when you
want to optimize your Warrior you should try to get the newest Warrior that
available. CW and the Königstuhl are a good Source. So you can see trends
and try to create something that can take his advantage out of the
situation on the Hill.

Sascha

--
Parlez vous Redcode?
Anonymous
April 29, 2004 5:05:01 PM

Archived from groups: rec.games.corewar (More info?)

wackoyacko2000@yahoo.com (Andrew Hunter) wrote in message > But whaddya mean, separated?
> 2223 cells (the current step) apart, we have pairs of instructions
> like this:
> 0000 spl #2,#1
> 0001 mov @0,}-1
> (and the same thing at 2223,2224)
>
> Um, what's bad about that? I'm kinda confused...how do you write
> incendiaries that are meant to be seperated?

Like this:

0000 spl #0,1
..
..
0020 mov @0,}-20

At least that's the way Torch does it.

Paul Kline
Anonymous
May 1, 2004 2:26:42 PM

Archived from groups: rec.games.corewar (More info?)

> > Um, what's bad about that? I'm kinda confused...how do you write
> > incendiaries that are meant to be seperated?
>
> Like this:
>
> 0000 spl #0,1
> ..
> ..
> 0020 mov @0,}-20

.... the gain being that this gives you two chances to hit something, while
throwing an adjacent SPL/MOV only gives you one. You are currently throwing
2 heavy bombs, both incendiary, in 6 cycles so 0.33c. This isn't good
against other bombers; Torch manages 2 bombs for 0.50c in a smaller loop for
better performance. Against replicators your design may well be better
because it throws more incendiaries.

Robert
!