[Home]Archer

Robo Home | Changes | Preferences | AllPages

Author: Ph

How competetive is it?

[Current rating at RoboRumble]

Where can I get it?

Archer 0.6.6 - http://www.robocoderepository.com/BotDetail.jsp?id=2326

How does it move?

It uses random movement based on PEZ's RandomMovementBot. Flattening based on Aristocles by PEZ.

How does it select a target to attack in melee?

1v1 bot only.

How does it fire?

It uses segmented guess factor gun.

How does it dodge bullets?

It is an avoider, still moves quickly.

How does the melee strategy differ from one-on-one strategy?

1v1 bot only.

What does it save between rounds and matches?

Can I use your code?

Yes, sure! It is included in the jar package.

What's next for your robot?

Primary objective is better movement, but I will also try to tweak my segmentation.


comments, questions, feedback...

Ok, just a couple of things. You say you pick your enemy in melee by bullet travel time. Would it not be easier to just pick according to whoevers closest, as unless you have an elaborate firepower calculation the 2 will produce the same result. You might also want to put in some kind of buffer so you dont "thrash" between enemies. Only changing when another enemy is less that 90% of the distance to your enemy seems to work well. Also, do you avoid enemy bullet impact positions all the time, even when there are 10 bots left?? If so, you might be able to improve your melee performance by waiting until there are only say 4 bots (That's what Ray Vermette used in TheArtOfWar) remaining. As when the melee is still in its founding stages, you have no idea whether the energy drop of the opponent is due to firing or not. Either that or just avoid the spots if the enemy has hit you within a given time frame. Admittedly i havent read your code so you could be doing all of the above. Good Luck!! --Brainfade

Thanks, your advice applies to Musketeer too (Archer and Musketeer use the same movement and target selection method). But I don't pick enemy only by bullet travel time - see TimeToHit. I take into the account gun turn time too. So I think this strategy avoids "thrashing". What do you think about my segments? I use segmentation across:

-- Ph

Why wouldn't you know if an energy drop is from an enemy firing or not when there are many enemies? -- PEZ

Well it applies in any case when there are more than 2 bots, but it is just more likely when there are lots. Say if in between scans an enemy doesnt fire, but is hit by a power 3 bullet its energy will drop by 12 points. If a power 3 bullet it has already fired hits another bot it will receive 9 energy points, leading to a net result of -3 energy taht makes it look like it has fired a power 3 bullet when it hasnt. Also with lots of bots collisions are more likely to occur and the resultant damage could easily be confused with shot's being fired. I've always thought that at the start of a melee it is better to concentrate of avoiding the massive scrum of bots that seems to occur rather than trying to avoid single bullet hits. That said all my Melee bots suck. As for your segments, i have no idea. You'd need to speak to one of the melee masters (Paul Evans, Rozu, ABC, Kawigi etc.) though i would have thought that the enemy absolute heading would have done nothing for you. --Brainfade

Enemy's heading is actually quite handy to a degree. If any enemy is moving with a very narrow profile to you (almost diving straight in and out) then they exhibit a much different set of spikes than at a wide profile (near perpendicular to you). Though absolute heading isn't too useful as the measure of that, you might want to seriously consider a relative heading where 0 is pointing straight at you. -- Kuuran

It seems good. With this method I should recognize bots that stay perpendicular to me. I think enemy's absolute heading can be useful too, as a kind of "movement signature". -- Ph

I think all you're going to do is slow down learning. There's no real reason for a bot's behaviour to change as it's angle in the arena changes if you have no regard for position. A bot facing straight down will probably still behave the same if it's facing straight left if they're both perpendicular to you positions, the opponent itself probably won't even know there's a difference in the situation. The few small differences that may crop up (such as bots running longer when they're going the width of the arena than the height) can't possibly make up for the learning speed hit. -- Kuuran

I recently released new version, with enemy's relative heading segmentation axis added, and it performs better (approximately 10 rating points better). What do you think about it? -- Ph

There have got to be some serious issues with your bot, to be brutally honest, I also suspect the 10 point rise may be a fluke. I think that conceptually it's extremely good, with just various silly and/or implementation mistakes. I really like how you've structured the code, too, I wish I had that kind of patience.

Now, so far I haven't read all of your code (there is a lot of it) but I've read most of the gun code, some of the other code, and run it through the FloodGrapher gauntlet. Here's what I've noticed:

Assuming you keep your current segment layout, you may want to change the segment sizes to look something like: [12][2][5][3][3][31]. That would learn about 30 times faster (which, for the number of segments, is quite quick), greatly helping your RR@H performance. -- Kuuran


Fighting battle 33 ... ph.mini.Archer 0.6.6,arthord.micro.Muffin 0.6.1
RESULT = arthord.micro.Muffin 0.6.1 wins 350 to 0
Fighting battle 34 ... ph.mini.Archer 0.6.6,davidalves.net.DuelistNano 1.0
RESULT = davidalves.net.DuelistNano 1.0 wins 350 to 0
Fighting battle 35 ... ph.mini.Archer 0.6.6,jep.nano.Hotspur 0.1
RESULT = jep.nano.Hotspur 0.1 wins 350 to 0
Fighting battle 36 ... ph.mini.Archer 0.6.6,myl.micro.Predator 1.50
RESULT = myl.micro.Predator 1.50 wins 350 to 0
Fighting battle 37 ... ph.mini.Archer 0.6.6,mz.AdeptBSB 1.03
RESULT = mz.AdeptBSB 1.03 wins 350 to 0
Fighting battle 38 ... ph.mini.Archer 0.6.6,ntw.Sigsys 1.6
RESULT = ntw.Sigsys 1.6 wins 350 to 0
Fighting battle 39 ... ph.mini.Archer 0.6.6,ratosh.Wesco 1.4
RESULT = ratosh.Wesco 1.4 wins 350 to 0
Fighting battle 40 ... ph.mini.Archer 0.6.6,rz.Apollon 0.23
RESULT = rz.Apollon 0.23 wins 350 to 0
Fighting battle 41 ... ph.mini.Archer 0.6.6,strider.Festis 1.2.1
RESULT = strider.Festis 1.2.1 wins 350 to 0
Fighting battle 42 ... ph.mini.Archer 0.6.6,myl.nano.Kakuru 1.20
RESULT = myl.nano.Kakuru 1.20 wins 350 to 0
Fighting battle 43 ... ph.mini.Archer 0.6.6,myl.micro.Predator 1.50
RESULT = myl.micro.Predator 1.50 wins 350 to 0
Fighting battle 44 ... ph.mini.Archer 0.6.6,myl.micro.NekoNinja 1.30
RESULT = myl.micro.NekoNinja 1.30 wins 350 to 0
Fighting battle 45 ... ph.mini.Archer 0.6.6,kcn.percept.PerceptBot 2.3

I think you've got a bug. --David Alves

Executing battles ...
Fighting battle 0 ... ph.mini.Archer 0.6.6,md.November 1.0
RESULT = ph.mini.Archer 0.6.6 wins 3594 to 1969
Fighting battle 1 ... ph.mini.Archer 0.6.6,lrem.Spectre 0.4.4
RESULT = ph.mini.Archer 0.6.6 wins 3903 to 1263
Fighting battle 2 ... ph.mini.Archer 0.6.6,dummy.micro.HummingBird 2.14
RESULT = ph.mini.Archer 0.6.6 wins 3993 to 1928
Fighting battle 3 ... ph.mini.Archer 0.6.6,shrub.Vapour src124
RESULT = ph.mini.Archer 0.6.6 wins 3539 to 2121
Fighting battle 4 ... ph.mini.Archer 0.6.6,dmp.nano.Eve 3.41
RESULT = ph.mini.Archer 0.6.6 wins 5047 to 1067

I think it is not a bug in my code. I compiled it using JDK 5.0, so maybe it throws exceptions in your JRE. Probably I will be able to fix that quickly. --Ph

I have seen that with one of my bots as well. 350 to nil... I don't think there's anything wrong with Archer. But what's wrong I don't know. =) -- PEZ

I'm using 1.4.2. --David Alves

I'll upload version compiled with -source 1.4 version soon. --ph


Robo Home | Changes | Preferences | AllPages
Edit text of this page | View other revisions
Last edited October 15, 2004 15:26 EST by Ph (diff)
Search: