[Home]Horizon

Robo Home | Changes | Preferences | AllPages

HORIZON: To infinity and beyond!

The default page text fits this robot's name quite nicely.

/VersionHistory - /Questions - /HorizonGT - /GunResearch


Bot Name

Horizon

Author

AaronR

Extends

AdvancedRobot

What's special about it?

It is my first released bot to use wavesurfing and guess-factor targeting. Also my first bot to make it in the top 100 75 50 25.

Great, I want to try it. Where can I download it?

http://www.robocoderepository.com/BotDetail.jsp?id=3286

How competitive is it?

RoboRumble rankings: see /VersionHistory

Gun statistics: see /GunResearch

MovementChallenge2K7:

Bot Name Author Type HOF SPL GRG Sub 1 WAY (Sub 2) GR3 RKM Sub 3 ASC CC CHK Sub 4 Total Comments
Horizon 1.0beta4 AaronR WS/DC 97.47 86.26 84.54 89.42 67.64 65.04 80.31 72.68 22.03 37.11 31.84 30.33 65.02 1 season

How does it move?

Wavesurfing, tracking guess factors with DynamicClustering.

How does it fire?

Guess-factor targeting, tracking guess factors with DynamicClustering.

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

Used to have some melee strategy involving MinimumRiskMovement, now nonfunctional in melee.

What does it save between rounds and matches?

Between rounds, the surfing and targeting data. Between matches, nothing, but I would like to add some data-saving features in the future.

Where did you get the name?

The same way as all of my other bots: it just sounds cool.

Can I use your code?

Absolutely.

What's next for your robot?


Comments, questions, feedback:

Up 16 places with 0.9.6, what's new? -- Skilgannon

I took your advice and made the bot do all of its clustering and sorting of scans at the time the relevant wave is fired. It seemed to help the surfing a lot, it shot up the WSC2K6 scores close to 85. In addition, adding a default hit logged at GF 0 got the bullet damage scores vs. Bot A as low as 28 over 500 rounds. - AaronR

How much has it helped vs. bot B and C? I'm guessing it would have made a huge difference, because LT/CT only use data at the time of fire. Just wondering, are you using a rollingAverage for your surfing? -- Skilgannon

Since you are still a little bit below BasicGFSurfer, I'm thinking that you still have some bugs to sort out ;-). Looks like these are the bots with the biggest differences:

I watch battles against my problem bots, and go through the code looking for why it would have reacted the way it did. I haven't looked at your code, but if it's structured well you should have no problem finding them. Good luck =) --Skilgannon

You're getting mashed by any and every sort of pattern-matcher. How about adding a time-since-something segment in your surfing? -- Skilgannon

=( ...

Sorry I've been gone for a while, my workload has been nasty lately. I was just running some tests with the development version of Horizon when I noticed that the bot was skipping a ridiculous number of turns. So I fiddled with things for a while and eventually managed to figure out that I actually have two molasses-like sections of code:

  1. My twelve-way precise prediction.
  2. The part of the clustering code that adds and removes scans from the log.

It seems that I didn't notice this in my performance before because I never bother to run Robocode before starting my rumble client (for which I keep a separate Robocode installation), meaning that the default super-high CPU constant is used. So now I have to optimize my code, which is something I *really* hate doing.

-- AaronR

For your precise prediction, Krabb (I think it was Krabb) pointed out a clever optimization, assuming you're surfing more than one wave at a time. The idea is to get your full danger for all waves if you continue going in your present direction. Then when you're checking the "reverse directions" danger, you can break early if the danger is greater than your "continue" danger, even if you haven't checked all waves yet. --David Alves

Aha! It turns out that my precise prediction had nothing to do with the problem. Rather, the slow code was exclusively in my clustering implementation. Guess what the problem was: I was using java.util.LinkedList to store my log history. I replaced the collection class with a custom circular array structure, which eliminated the problem altogether. So basically, Java collections are slow and inefficient - but we knew that already. -- AaronR

I don't think there's more than a few percent difference between their LinkedList class and one you could write yourself. ABC brought that issue up once before, but it turned out he had been using list.get(int i) inside a for loop, so what should have taken theta(N) time took theta(n^2) instead... --David Alves

1.0beta9 seems to have made HUGE gains compared to 1.0beta8. Only 27 battles have passed, but I'm still gonna call it: I think it will be your ticket to The2000Club. Well done in either case! --David Alves

Alright, I'm an idiot. I released the MC2K7 test version of Horizon as the official version, meaning it had Raiko's gun. Ironically, it ranked about the same as RaikoMX... So for the second time in a row, I have been embarrassed by my gun only to find out that it means I have a very good movement. -- AaronR

Bah. On my journey from The2000Club to The2100Club, about 15 points were due the gun improvements. So, gun isn't that important. Rerelease with a decent gun and claim your prize! --David Alves

Although, wow, that is a lot lower. Are you sure your gun is bug-free? Can it hit Walls consistently and whatnot? A 120 point difference due only to gun sounds very wrong to me. --David Alves

I gotta second what David said. With that big a difference, I'd even wonder if you might have a bug that is making you just shoot with HeadOnTargeting... ? Sounds like you have a very strong movement, in any case, and I think that's usually harder than getting a good (or good enough) gun. -- Voidious

I watched some battles and it's definitely not firing with HeadOnTargeting, it hits walls well enough. Could there be a bug in the Angle -> GF -> Angle conversion process? For example if the target is moving clockwise around your bot, and it moves .5 radians in front of the GF0 line, maybe you store that as GF .7 or something, but when converting back to angles you convert the .7 GF to an angle of .8 radians and end up shooting too far ahead / behind... --David Alves

That's possible, but not likely, since most of the original source for the gun was from the largely bug-free GFTargetingBot. Also, much of the code is shared between the movement and gun, including some (but not all) of the GF conversions. I'll look into it, though - I may have broken something while I was fiddling. Maybe improving my debugging graphics will help me find the problem. -- AaronR

Just out of curiosity, how many scans are you searching through? And also, how much are you weighting each attribute? -- Skilgannon

My log depth is 7200, and my cluster size is 5. My weights are: distance = 2, velocity = 1, acceleration = 3.5, lateral velocity = 2, time since acceleration = 2.5, wall distance forward = 5. I know those weights seem odd, but the tests I've been running seem to indicate that that is the approximate order of importance of those attributes against low to midrange random movements (which of course make up most of the rumble). Against high-end random movements and surfers, it is much less important to weight wall distance high.

I think I have may have found the problem. I just created a test bot called WallsReverser?. It acts exactly like Walls for the first five rounds, then behaves like a mirror image of Walls (that is, circles in the opposite direction) after that. GFTargetingBot does what a correctly implemented GuessFactorTargeting gun should do with this bot: hit it just as well on the sixth round as on the fifth. It didn't care what direction the bot was orbiting in. However, when I put Horizon against WallsReverser?, it fired as if it was targeting Walls - completely ignoring the fact that the bot was now moving in the opposite direction! It figured out the new pattern fairly quickly, but that doesn't solve the problem. Worse yet, I have no idea what is causing this, since the GF-to-angle calculation is multiplied by the lateral direction like it should be.

-- AaronR

I would check that you are actually setting the direction to what the enemy's lateral velocity's is. Another thing to check is that you multiply both when you store the angle and when you use the angle to fire from. Shadow uses a MUCH larger log size (about 15K), and a much larger cluster size (50), so if it doesn't slow you down too much you might want to give that a try as well. IMO you should use lateral velocity or velocity, but not both. Maybe switch one to advancing velocity, and weight it lower. And just to check, you are normalizing your data for each attribute to values between 0 and 1, not -1 and 1, right? Absolute values of your lateral velocity are necessary, otherwise your gun won't see reverse the same way it sees forward. -- Skilgannon

Sounds like you're either multiplying by orbit direction too many or too few times, in either your Angle -> GF or your GF -> Angle code.

When saving a scan:

 GF = orbitDirectionAtFireTime? * Utils.angularDifferenceBetween?(gf0Angle, shooterAtFireTime?.absoluteAngleTo?(p) / Utils.maxEscapeAngle?(power)

When aiming:

 angle = angleToTarget? + Utils.maxEscapeAngle?(bulletPower) * GF * orbitDirection

Another possibility is that when you store a wave you're using the target's current orbit direction instead of their orbit direction at the time you fired. Incidentally angularDifferenceBetween?(fromAngle, toAngle) is just Utils.normalRelativeAngle(toAngle - fromAngle), but I like the name better. Before I put it into a method I was always forgetting which part should be on which side of the minus sign. =) --David Alves

(Edit conflict) Here are my responses to Skilgannon:

I would check that you are actually setting the direction to what the enemy's lateral velocity's is.

Shadow uses a MUCH larger log size (about 15K), and a much larger cluster size (50)

IMO you should use lateral velocity or velocity, but not both.

You are normalizing your data for each attribute to values between 0 and 1, not -1 and 1, right?

Absolute values of your lateral velocity are necessary

And to David Alves:

-- AaronR

Just a couple sidenotes: Raiko and GFTargetingBot should be very similar in performance, as they are both based on Tityus. Also, a log depth of 7500 seems fine, though other DC guns do use many more; a cluster size of 5 seems a little small, but not 100-points-below-Raiko small. =) Sounds like you have found the big bug, though, so best of luck in your quest for 2K! As for using absolute value of velocity / lateral velocity: I absolutely think you should do this. Why should -7 or 7 make a difference? Odds are the bot that's moving doesn't see them as different, and it will majorly inhibit your learning speed. -- Voidious


I'd like to thank Simonton for finding the massive bug in my gun. The bug was caused by - surprise, surprise - movement tweaks! When I modified part of my shared Wave class to more accurately detect wave intercepts for the surfing, I inadvertently destroyed the accuracy of the gun's logging algorithm. With that fixed, my rumble scores should improve considerably. -- AaronR

This looks like an awesome jump, if it isn't a 2020+ I'll be surprised [Comparison]. -- Skilgannon

Looks like you'll have yourself a ticket into The2000Club once you reach 1000 battles... get those clients running, people! =) --David Alves

In addition to fixing that bug, I also introduced several other tweaks in the 1.0betaF4 release. I'll have the full version history for the 1.0betaF series ready as soon as I can remember all of the changes I made. -- AaronR

Wow, almost 20 points to 2056, nice work! So much for it being buggy... =) -- Voidious

Nice work! I might just have to borrow your MEA calculation stuff - see if it also gives me a 20 point boost =) -- Skilgannon


Robo Home | Changes | Preferences | AllPages
Edit text of this page | View other revisions
Last edited November 15, 2007 17:40 EST by ec127_sws14.labs.coe.fit.edu (diff)
Search: