0.5:
0.6:
0.6.1:
0.6.2:
0.6.3:
(Completed tasks have "done" and a date afterwards.)
(Fixed bugs have "fixed" and a date afterwards.)
| Version | Rating | Rank | Percentage | Date |
| 0.5 | 1629 | 175/408 (later 263/625) | 57% | 1/30/06 |
| 0.6 | 1729 | 174/625 | 72% | 4/20/08 |
| 0.6.1 | 1707 | 197/625 | 68% | 4/22/08 |
| 0.6.2 | 1752 | 159/625 | 75% | 4/23/08 |
| 0.6.3SP | 1750 | 172/637 | 73% | 6/8/08 |
I may be wrong about that, PEZ, but i'm not focusing on it at the moment anyway. First, I have to figure out why my WaveSurfing (based on a very small number of battles right now, so anything could happen still, and I could be wrong...) didn't seem to help my rating much, and whether I should focus on movement or targeting. -- Greywhind
Focus on movement. Plug in my Bee gun and focus 100% on movement. That way you'll have a measure on your movement as it compares to CassiusClay's. As long as you're not going 2000+ points this way something is broken in your surfing. Then when you break the 2000 wall you can focus on targeting trying to get your bot above 2000+ again. When you've reached that goal you can get back to the movement-or-targeting issue. The stuff about using Bee is just a suggestion. But the focus on movement thing is advice. Advice from an old gun nut who learnt the hard way what really matters. =) -- PEZ
Yep, I definitely second PEZ's advice on focusing on movement. (He gave me the same advice. :)) Getting flawless WaveSurfing is a lot harder than getting a good GuessFactor gun going, and you can pretty much take everything you learn from WaveSurfing and apply it to GuessFactorTargeting. For me, the main benchmarks I used were the WaveSurfingChallenge, and then beating Barracuda and Noran.BitchingElk? by ratios of 20:1. -- Voidious
Thanks for the advice, PEZ and Voidious. I'll try all of it. -- Greywhind
Well, the results are in for StrengthBee? and the MovementChallenge2K6. StrengthBee? went to place 73 in the RR@Home, telling me that I have 140 points to gain in gun and 290 points to gain in movement to get to where CC is. Seems like a lot, but I think I may have a way to improve my movement vastly... then again, I've thought that before... Thanks for the use of Bee for testing, PEZ. -- Greywhind
Having PEZ's pluggable code available is an excellent testing tool, ain't it? Anyway, once you get your WaveSurfing really working right, you will start gaining points *very* quickly! -- Voidious
Actually, on the topic of wavesurfing, I'd like to explain my methods. My first version of Strength found the 3 most likely angles of fire for each bullet in the air and predicted its movement at all possible velocities to find ones that didn't intersect any of these predictions. Although that worked fairly well, it wasn't quite what I had hoped for.
My new version of Strength, which I am testing now, still uses Line2D.Doubles to predict the enemy's fire - but instead of three, it uses all the possible angles and then rates movement based on how likely the enemy is to fire at all the lines it would intersect. Also, it only predicts forward at full speed and backwards at full speed, but it does so at every tick rather than once per bullet fire.
Hopefully, this will be successful. If it is, I'll release a new version in the Rumble. -- Greywhind
Why lines? It isn't dangerous to intersect the line of fire from a bullet that is far away, is it? Or maybe I am misinterpreting what you just said. -- PEZ
It does sound like you might be overcomplicating things... The key point is just to be at a safe spot when the bullet gets there, right? In any case, it looks like you're making great progress on your WSC scores. -- Voidious
Well, the idea of my WaveSurfing is to be at a safe spot when the bullet gets there. It does so by finding the safer direction each tick (forward or back), based on how likely the enemy's bullets are to be aimed at my robot's predicted future location when they arrive.
To find this likelihood, Strength simply keeps track of the danger of each GuessFactor and then checks which GFs will hit it when it moves, and how dangerous they are.
Currently, I'm experimenting with the size of my bot's predicted area, whether or not I should add to the danger of guess factors ONLY when I get hit, and how exactly to count the danger of a predicted location (add all the dangers it intersects, or take the avg. danger) -- Greywhind
Please do not improve too fast, otherwise I will fall out of the top-50 and currently I have no time to spend on GrubbmGrb's movement. ;-) -- GrubbmGait
I suspected that my robot was slightly off on the number of turns left until the next bullet would hit, so I made it print out how many turns later it thought it would be hit than when it actually was. The number varies from 0-3, and sometimes gives strange values like 16 and 50, but I think those are due to thinking it would be hit earlier than it was. My question is how this number could vary so much, and how I can fix it. -- Greywhind
How did you test it? Standing still and let yourself be hit? Then it shouldn't vary much. If you're moving about I guess it can vary some depening on if you get hit from the front or if you drive into the bullet. Can you give us some more details? -- PEZ
Ah. That was it. Thank you - I was indeed 2 ticks off on the bullet prediction. We'll see if the correction improves my scores. -- Greywhind
I have come to the conclusion (incorrect as it may be) that my WaveSurfing's difficulties are attributable primarily to my movement prediction - my next task will be to attempt to use the FuturePosition methods to predict my movement and see if it helps. -- Greywhind
FuturePosition is giving me good results - except for one problem. Intermittently (about 1 round in 5) my robot will sit in one place changing direction constantly as its predicted location spirals in towards it like below, whereas it should show something similar to the 2nd "pic." below:
![[Home]](/images/RoboWiki.png)
\ -----R-----
\ Can anyone relate?
\ If so, please tell me
R
\ what you think might
\ be wrong.
\ -- Greywhind
The only thing that comes to mind is that you might be using degrees instead of radians as input to and/or output from futurePos(...)? FuturePosition uses radians... That's all I can think of right now, but I might be able to help more if you posted some code. -- Voidious
I believe the problem may well have to do with the output I'm getting from WallSmoothing - I think it uses BackAsFront, and I don't think I'm taking that into account... also, I might be feeding the WallSmoothing incorrect direction data. -- Greywhind
I now take into account the correction for back as front in angle when I do my movement prediction, but in some rounds Strength moves towards the wrong side of my movement now, leaving it constantly switching direction and getting destroyed. I can't figure out what conditions this happens under except that it seems to happen when back as front kicks in. I'm going to upload the current version to the repository under the name StrengthBeeMC? (meaning gun is disabled) - if you want to help, DL it. Code is included. Thanks. -- Greywhind
The first thing I searched in your code was the 'setAhead' commands. You use these in two different ways: setAhead( number) (line 240) and setAhead( number * direct * direction) (line 260). Every time you get into the situation that the first variant is executed, the variable 'direction' may point the wrong way afterwards. The reason why you have more than one setAhead() is unclear to me, one should be enough. Just a very brief observation though. -- GrubbmGait
In my copy of the code, which should be the same you have, the setAhead(number * direct * direction) on line 260 is commented out. That shouldn't affect the robot's behavior. In fact, the variable direction currently is arbitrary to the robot's actual movement, and it's only changed when the robot hits a wall, although that doesn't matter at the moment as it isn't taken into account anywhere else. Thanks very much for looking at it though. If you happen to think of another possible problem, please let me know.
By the way, I'm using Robocode SG to do graphics - they show which direction the robot should be going (green is the prediction for the chosen direction, red is the prediction if it reverses from its current direction). I don't currently evaluate stopping, although I plan on adding that later. -- Greywhind
I should stop looking at code with Notepad :€ I will try to take a further look today. -- GrubbmGait
I believe I have fixed the problem - though perhaps not at its source. Since the predictions were being switched when I used BackAsFront (on WallSmoothing), I simply noted that occurrence as a variable and switched my movement direction accordingly. It worked, and I then added dive protection, bringing my testing scores up to an all-time high. The next MovementChallenge release will come soon, and maybe even a rumble release. -- Greywhind
My latest tests are giving me 93-95 (MovementChallenge style) against WaveSurfingChallengeBotA. I think the next objective here is segmentation. If anyone has tips or questions, please put them below. Also, I'm going to officially release the next version of StrengthBee? into the RR@Home. -- Greywhind
Well, folks, I've done it again. Once again, I failed to test against ram bots, and therefore got creamed by them compared to my expected score. Just goes to show you that you can't ignore any bot types in testing. -- Greywhind
I would bet you still have significant bugs in your WaveSurfing code, although that score shows that you must have a pretty solid base of working code, too... it's possible to get very high WSC scores and still have bugs in your WaveSurfing. Segmentation is important, but as long as you have reasonable segments, I think there's more to gain in perfecting your WaveSurfing code than in finding better segmentation. Besides, you'll need to re-tune the segmentation once your WaveSurfing is perfect, anyway =) -- Voidious
I probably have some, but I'm not sure what... I'll take a look after I've fixed the anti-ramming. -- Greywhind
No, my anti-ramming code isn't done... but I'm more interested in the surfing, so... I found a couple of bugs/possible improvements: 1. I had a one tick hit time difference from expected. 2. I wasn't (haven't fixed this yet) using a BulletTravelTime prediction that changes to take into account my movement towards/away from the enemy. 3. I still don't have a very accurate robot bounding box... I'm using a non-rotating box size 50, which seemed to me to be safer than using the robot's actual size... any suggestions Voidious? I know you've been working on this. 4. I updated my radar system to be similar to my other bots. I noticed that some bullets were getting missed because of missed scans.
One more thing - the calculations of my movement prediction seem to be consistently off by +/- 0 to 10 or so for my x and y (separately) on each bullet - not sure why this would be since my calculations use the FuturePosition code from this wiki, and even when I stand still the entire time the bullet is in the air my predictions are off by 0-3... Any ideas?
In testing, my newest version gets 97.76 (MC style) in 100 rounds against WSC Bot A. -- Greywhind
That's another very good jump against BotA, so nice work there. As for bot width, my recent experience indicates that it's actually better to underestimate this than to overestimate it, as surprising as that seems. CassiusClay just uses a radius of 18, and you know how well he surfs; I'm now using a computed value between 12.7 and 18. I'd say a good surfing system will very rarely be close enough to the bullet of a simple targeter for this to matter too much, but near walls it helps to be nearly accurate so you can weave through a couple of bullets to get away.
When you stand still, your FuturePredictions? are still off? Or just the tick that intercepts is still off? If it's the first thing, then something is wrong that I would have to see code to help you with =) But if it's the intercept you mean, it seems like a miscalculation of the wave source and/or the fire time. If you detect an EnergyDrop on tick x, with the drop being between tick (x-1) and x, then the source of the bullet is their location at (x - 1), the fire time is from (x - 1), and the last scan they were able to use to aim was from (x - 2). (They saw the scan at (x - 2), they aimed; on (x - 1) they called setFire or whatever; on (x) their cannon shot before turning the gun any further.)
Hope some of that helps =)
-- Voidious
The score above (97.76) was a slight fluke - but with more accurate bot width it becomes more steadily close to 96.5-97.5.
I will post in the Repository tomorrow (probably) a version of the bot with debugging msgs. on. If anyone finds a possible reason for my prediction problems, let me know. To turn off movement, there are just two setAhead lines to comment out. They're somewhere around line 300.
It seems like the more I am moving in a direction during the bullet's travel (like more x-axis change than y), the more error there is in that axis.
I'll check the data that I'm using for the enemy's shots, but it shouldn't affect things when I stop...
-- Greywhind
I've fixed the movement prediction - it was due to the 2-turn early removal of each wave... also fixed that... -- Greywhind
Strength 0.6 is just StrengthBee? 0.6.2 with the Bee gun removed and replaced with Strength's original gun. -- Greywhind
Well, it looks like 0.6 has gained almost exactly 100 points from 0.5, which I think is a pretty decent jump. I'll have to actually find the time to add segmentation and a totally new gun to get much higher though... we'll see. -- Greywhind
So I'm uploading Strength 0.6.1, which is the same as 0.6 except that I added an anti-ram mode. -- Greywhind
Seems like the anti-ram mode worked perfectly against ram bots, adding at least 20, and as much as 50, percent to 0.6.1's score over 0.6's score. However, I believe it is kicking in too frequently against other bots, bringing down the overall ranking. I'll play around with the conditions under which it switches modes and see if I can remove that problem while keeping the score up against real ram bots. -- Greywhind
My limited testing shows 0.6.2 to perform almost exactly as well as 0.6 against non-ram-bots and almost as well as 0.6.1 against ram bots, so we'll see how it goes in the Rumble. -- Greywhind
Looks like 0.6.2 was a success - it gained 22 points over 0.6's general ranking, and against ram bots, it improved the score from 0.6 consistently by 30-40% while losing little, and often gaining, score against other types of bots. -- Greywhind