Archer

Author: Ph

How competetive is it?

[Current rating at RoboRumble]

Where can I get it?

Archer 0.6.6 - https://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?

• Between rounds - GF stuff.
• Between matches - nothing.

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:

• enemy's distance to me
• enemy's distance to wall
• enemy's velocity
• enemy's heading (I don't know do I really need this segment)

-- 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:

• Your learning is too slow, even if you saved data your learning would be too slow. This version of Archer (0.1.3) learns a fraction over 207 times more slowly than KostyaTszyu?, for example. You need to change your segmentation granularity, which is what regulates learning speed.
• 6 segments is probably not enough for distance, you might want to use 12.
• 2 segments is realistically not enough for velocity, you probably want to use 3 (0-2, 3-5, 6-8)
• You might want to change your wall segment to take into account whether the enemy is within the threshold distance of a wall AND moving towards the wall (facing towards and moving forwards or facing away and moving backwards). If an enemy is just near a wall but the wall isn't affecting it's path you usually won't see the behaviour change that wall segments help you identify.
• I've already given my thoughts on the heading segment, and regardless of it's usefulness it's too big. 37 segments is about 30 more than anything outside your distance segments should have.
• See above for bearing segmentation size.
• I didn't mean relative bearing segmentation when I said it's useful to segment on a relative measure of heading. What I meant is a segment that measures how "steep" the opponent's approach to you is. You'd only need about 3 segments, one for an opponent who is moving close to perpendicular, one for an opponent who is moving in the vicinity of 45 degrees towards or away and one for an opponent who is moving right at you. You could also differentiate between towards and away, even then you only need about 5 segments. Bearing doesn't measure this. The bearing of your bot relative to the opponent bot's heading (what they'd get from e.getBearing()) is probably what you want to use, once you have that angle you'd do something like Math.abs(angle) for angles 90 and under, and 180 - Math.abs(angle) for angles over 90, keep that if the velocity is positive or take Math.abs(180 - resulting angle) if the velocity is negative. Then that would give their angle of attack. That's off the top of my head, but I think it works. You should probably get your gun working without this segment first.
• Your movement gets you stuck standing still on walls quite often. This is really getting you butchered.
• Your movement shows flashes of adaptivity, but often then goes straight back to either running straight lines into a wall or standing still. You might want to experiment with your gravity point weightings, especially for walls.

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