Archived talk:Locke 20040719

Locke Sub-pages:

Locke - Version History - Archived Talk 20040719

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

I may have a bug in the projection from 2D to 1D. Found this after chatting with PEZ and ABC about GuessFactors. Am chasing it right now, hoping it will cause Locke to jump in the ranking.

• No, the projection works fine. So no potential points to be gained here. It looks like a bug because of the weighting system. Observations with different ETA's than the current situation could drag the aiming a little off. I tried to solve this in 0.5.1 by increasing the weight of the ETA dimension, meaning the segment borders will depend more on ETA accuracy. --Vic
• Well, that does not work. Lost 8 rating points...

Actually I found another bug after that chat: my Waves were not properly aligned. I failed to take into account that bullets may have different bulletpowers. Thanks to jim for providing the answer to that one. Strangely, this fix seems not to improve the rating at all!

• In fact I lost 7 rating points with this bug fix! And I used RobocodeGLV014 to verify that the waves are now perfectly aligned! This blows my mind.... --Vic

It seems I was still using an older version of Raiko's movement. As I am comparing the two guns through the RoboRumble, I should have the same movement. Also, I found out that in all my previous versions I had broken Axe's MusashiTrick. That has been repaired now. I expect a big jump in rating points! --Vic

• YEAH! Locke jumped 50 rating points to 1870, entering the top 20 in the RoboRumble! That means that there is a difference of 60 points with Raiko, who shares the same movement. So, if I can gain 60 points with improvements on my SOOL gun, this gun would be Raiko's equal. And then beyond :-)

Question to you top guns out there: This high in the rankings, where points are hard to find, can 60 rating points be gained by only tweaking a gun? I should mention that this guntype is brand new, and has some (probably small) known bugs, and hasn't been tweaked very much. --Vic

Maybe the question is old. But I just saw it. The answer is a definite YES. -- PEZ

Hmm, interesting. Watch this space ;-) --Vic

In version 0.5.3 I now fire waves every tick. I'm curious how that will translate to rating points. --Vic

• very disappointing. It dropped two points. Have all you people who at one stage implemented this had good results with firing waves every tick? Maybe there are some special tips and tricks on this subject? please advise :-/ --Vic
• In theory when you fire waves every tick you lose some accuracy against bots that react to fire. If you run TGrapher against these bots you'll notice that it draws different graphs for "real" waves and for "virtual" ones. However, if your statistics are heavily segmented the learning speed drops dramatically if only real waves are collected. And it seems that the right mix of heavy segmentations can compensate some for the fire-reaction of these bots. Particularly the time-since-velocity-change segmentation helps in this. So, it might be that your stats are not segmented enough for you to need firing waves every tick. It could also be that you lack the right mix of segmentations to compensate for the "virtual" wave inaccuracy against some bots. A boring alternative is that you have a major bug in your gun code somewhere. Then it won't matter much how you collect waves. I have had those situations many times. And, 2 points drop is probably within the margin of error anyway. -- PEZ
• If the major advantage of this to segmented GF guns is to increase learning speed that might explain it. Locke's gun has Dynamic Segmentation. Simply put, it starts with one segment, and when it has enough data it kinda splits it into more segments etc. If I quickly fill this first segment with data collected every tick I basically have a bad quality (large spike) segment against flattener movement bots (but not against 'spike only' bots like walls and spinbot... too bad there aren't more of those in the rumble ;-). That segment will eventually split into slightly better segments but that would take probably as much time as only collecting real fire waves. With a GF gun, the fixed segments are an advantage in this case, because they can never have bad quality data (I assume you use fixed segments without stealing from neighbouring segments when you have little data). Then again, you may be right and I may have a major bug in there yet. Thanx! --Vic

---

v0.5.6 discussion:

Does anyone have experience with increasing firepower for weaker opponents? My theory is that if it is weak enough, you can trade a little accuracy for more bullet damage points. This also shortens the matches which will give the opponent less time to hit you and get damage points. I was convinced this would work. But in practise, it doesn't seem to gain any points for me. After some thinking I have found that maybe the higher firepower bullets expose some of the guns weaknesses which counterbalance the score gain, such as less data in higher power segments and maybe buggy BulletETA interpolation, when using less power segments to fill up the missing data. So, my question: who can tell me if this is a dead end street, or a definite rating point gainer (if I get it bugfree)? --Vic

• Very interesting idea... Please let me know if u succeed. -- Axe

• The first results are disappointing. Lost 7 rating points. The question above still stands: has anyone experimented with this technique? --Vic
• I would think that the problem with this is to accurately find out that you are dealing with a weak opponent. You could be facing a very strong opponent and just have some very good luck in the first couple of rounds. Or am I missing something? -- PEZ
• I think that was not so much the problem, but I may be wrong. I compensated for the luck factor you mentioned by gradually boosting power as the match progresses. So say in round 5, even if Locke wins all first four matches, there is hardly any bullet power increase. But in round 35, when Locke has won at least 75% of the rounds, it will fire power 3 every shot. While writing this down, I'm thinking that 35 rounds per match is probably too short to reasonably assume that one bot is better than the other. But maybe I'll try again later with much more conservative parameter values (never increase power in the first 10/15 rounds, only increase power if winning 80/85%, max power 2.5, not 3.0). --Vic

---

v0.5.8 discussion:

I'm beginning to suspect that I'm on the wrong track. If this version (with two true bugfixes) again performs worse then there must be a major issue with Locke's gun which must be resolved first. --Vic

• Well, fortunately it didn't perform any worse this time. But not better either. :-| I've spend the good part of a day aligning waves and getting ETA right (see BulletETA page) and it didn't change a thing. The whole 0.5 branch has basically been about better accuracy. It seems that Locke's gun has bigger problems than that. Still have 60 points to try and gain before catching up with Raiko's gun. --Vic

I think you cant compare your gun with that of Raiko's in the RR. R used a really smart segmentation that works amazing straight after a few rounds. Of cause a SOOG should perform better but remember that it needs lots of ronds to find the "perfect" segmentation for each enemy. To find out the true performance of your gun you should compare your and Raikos gun over 500, 1k ... rounds, imho --deathcon

Actually I designed this gun to be a quick learner as well. And against Walls and Spinbot it does learn very fast :-p. I have observed in a lot of battles that Locke outperforms the opponent in the early rounds, and as the opponents gun comes up to speed the match becomes more equal or even turns around. But I do think you are right that the difference in Segmentation is very important, and may be a weak spot of Locke at this time. Fortunately I have hardly worked on tuning that part of the gun, so I think there is a lot of progress to be made there.

I'm definitely not sure that this gun should in theory perform better then Raiko's gun. The SelfOrganizingObservationLog is just an idea that I came up with, which in theory has some advantages over GF targeting but may also have yet undiscovered weak points. And in practise, GuessFactor targeting has evolved over many years now, with many people working on it. Raiko's gun has hand-tuned, fixed Segmentation that has proven to be very, very, very efficient as you point out. It remains to be seen if Dynamic Segmentation the SOOL way can converge to that level. But I sure as hell will give it a go ;-)

One thing I will address soon about Segmentation: Raiko's gun is heavily segmented. But not all segments are equal. Some segments will get much less data, but to compensate these segments are much more predictable (for example a close to the wall segment, or a segment where time_since_last_decelleration has a high value). Basically these segments result in Situational targeting when used, and play a very important role in the first stages of a match. Other segments are not so predictable and need lots of data to reveal patterns in the opponents behavior. These segments start playing a role later on in the match when there is enough data, and when used they classify as Statistical targeting. In Locke's gun this distinction is not yet made as all Segments are of the some size (same number of observations). This probably results in Situational segments polluted with too much irrelevant data and Statistical segments that have much to little data. The trick will be how to determine how big a segment must be. I'm thinking along the lines of calculating the Entropy of a segment and grow or shrink it accordingly. Any thoughts on this?

--Vic

I had a quite similar idea of a SOOG gun but if was so slow and didnt work 100% accurate i threw it away. My idea was to store all waves of my gun in an array. These waves had a field that contained an array were i put many information about my enemy in, like: current speed, last speed, heading change since last scan, distance to wall/center ... .Then i had an array in which i saved the priority of all these values. So when my gun was cool and able to shoot i iterated all past waves and compared them ( their values ) with the current enemies value and took the 100 best of them. For the compare algo i used the priority array mentioned above. With these best factors i calculated that one found most with a certain tollerance and shot with it. After each round i compared all waves to find out which value the guessfactor influences much and which not so much and increased the priority of those that did. What do you thing about this??? If u understood something not because of my bad english or my strange way to exlpain things just tell and i will try to rephrase. --deathcon

Wow! That sounds amazingly like Locke's gun! I also keep an array of waves (Log) with situational data, dynamic priority (currently that is fixed, but changing priorities after each round is already designed). One difference is that I preorder the waves (I call them observations) to make the search process faster. I did not understand this sentence: "With these best factors i calculated that one found most with a certain tollerance and shot with it.". Do you mean you choose the single best wave and use that for aiming? In that case that is also a difference with my gun. Locke does MultipleChoice of the best 49 (currently) waves. Your gun would then basically be a Situational targeting type gun. So how did you store the opponent's movement when collecting waves? Did you store a GF, or distance+heading or what? --Vic

I store GF's (real factors no factor index).Here a rephrase of my sentence: I take the factors of the 100 best-matching waves. What i do then is similar to abc's MultipleChoise. I take something like an average of these factors and shoot with it. better? --deathcon

Yep, thanx. I've been considering using GF's as well for performance reasons, but heading+distance which I'm using now does have its advantages. I'm sticking with that for now. The major difference then is the preordering of the array. That was the idea that started me working on this gun in the first place because without it I knew there would be performance problems. Still, amazingly similar! --Vic

Sure and i wish you good luck. I threw my code away but hopefully you get bring it working. Maybe i will take my code someday and continue but not in the next time. Watching this place and the rankings ... --deathcon

I guess this kind of thing happens all the time. I wonder how many people have some rusty little bot somewhere in the corner of their garage with WaveSurfing movement that they did not get to work properly? I know of at least one :-) --Vic

---

v0.5.9 discussion:

The 0.6 branch will take me a little bit longer to work on, so in the mean time I'm trying out some smaller tweaks and doing some general sanity checking. For starters, I am wondering if a smaller fixed segment size (more Situational Targeting) or a bigger fixed segment size (more Statistical Targeting) will produce better results. Currently I'm using 49 observations per segment. I'll try 15 and 149 respectively. --Vic

I think you might have a bug in your gun. From what I understand of it it sounds like the gun should perform really well. What segments/properties do you use to sort the log? -- PEZ

My Possible Bug list is growing very short. The only think left to investigate is how I adjust distance travelled with differing BTT's (as we are coincidently discussing on the Shiva page). All other bugs have been eliminated or fixed I think. In fact I think there are 2 main reasons for this gun to underachieve:

• fixed segment size (see 0.5.8 discussion). I will address that in the 0.6 branch.
• the log sorting means that similar Observations will be in each other's neighbourhood. But that is not a perfect science, compared to the fixed segments of GF Targeting. It may happen that relevant observations are not used in the actual targeting because they are in a different, but close, neighbourhood.

At this time Locke uses the following segmentation dimensions:

• MyBearing (RelativeHeading)
• BulletTravelTime
• Velocity
• CenterBearing (Bearing of the BF Center)
• Distance to closest Wall
• Distance to closest Corner
• TimeSinceLastDecelleration

(I have more dimensions waiting to be added (like Accelleration), but I first wanted to make sure the gun was working properly.)

The Log is sorted by inserting a new Observation inbetween the two closest existing ones in the Log. This closeness is determined by a distance() method, which basically is a Pythagorean distance over all 7 dimensions. Here's the code:

    int distance(Situation other)
    {
        int result = 0;
        for(int i = 0; i < NumDimensions; i++)
        {
            result += (weight[i] * Math.pow(dimension[i] - other.dimension[i], 2));
        }
        return result;
    }

Notice I don't do the Math.sqrt() in the end. This is basically for performance reasons and I didn't think it would have any bad consequences, because I'm only searching for the minimum in the Log. The weight array holds different weights for each segmentation dimension. All are 1.0 at this time, except for the RelativeHeading, which has a heavier weight. This tweak gained me 12 points in the Rumble.

--Vic

Ummm, OK, you might be bugfree then I guess. If it easy to do I would exchange relative_heading for last_velocity (and thus nail all acceleration segments at once). And change time_since_deccel to time_since (last_velocity != velocity). According to my tests relative heading isn't too effective. And checking the time_since_velocity_changed for most enemies happens to catch both time_since_deccel (low) and time_sine_accel (high). You can always change back if I am wrong about this. -- PEZ

Oh no! I'm not saying I am bugfree! I just don't know where any bug(s) might be at this stage. Anyway, thanks for your pointers. I will test them in the next version. I will also include your firepower=1.9 and distance segmentation tips. Let's see what happens. --Vic

Interesting things happened with the segmentation size test. It seems smaller segments (more Situational targeting) work better than bigger segments (more Statistical targeting). This especially shows against the surfers. Maybe this is another clue to the discussion on the GhostBuster page about surfers performing worse against PM guns. Situational targeting shares a lot of properties with PM targeting.

Another thing was surprising: using bigger segments eliminated all my extreme problem bots! So it seems those problem bots need Statistical targeting. This again points me to the direction of Dynamic segment size.

--Vic

I'm not a VirtualGuns advocate usually. But this sounds like a case where it could work. Can you collect data in such a way that you have both small anmd large segments available and pick out two gun bearing suggestions? Measure the unsegmented performance of both virtually (I would use raw virtual hit rates rather than which one is usually closest), and always use the one with the best stats over all? I mean, no rolling stats or anything fancy. -- PEZ

Maybe that would work, but I'd rather try and design this gun in such a way that it converges to the opponent's particular weaknesses in a more elegant way. VirtualGuns would be my absolute last resort, when all else fails. ;-) --Vic

Ditto that! Even though i think raw == elegant, but then I do design Pugilists, don't I? =) -- PEZ

---

v0.5.10 discussion:

the PEZ branch.

In this branch I will test all the tips PEZ has given me from the kindness of his heart :-)

For starters, I have taken his incredibly complex firepower algorithm to the testbench. Let's hope it works out!

--Vic

=) Check question. d < 180. That's what I do yes. But it's also on a segmentation indexing boundary. Which is important. Is it so for this Locke too? -- PEZ

Well.. I don't know. Locke has no rigid indexing boundaries. I could speculate that around d==180 there may be some heavy extrapolation (because the neighbourhood will spill over that boundary) that could mess up aiming, so I guess it may be important. Maybe in Locke's case I should sort of fade the bulletpower from 1.9 to 3.0 between distances 180 and 140. I mention 140 because that is where Raiko's gun starts firing 3.0.

Initial results are good: +8 points. Thanks for that, PEZ! And I even introduced a small bug in there, so the next version should gain even more points.

I did notice something interesting: Although my rating score went up 8 points, my number of losses almost doubled. Maybe (hopefully) that is because of the bug. But I think not. I think it can be explained by the fact that my power management was much more conservative than yours. Locke often won matches on survival against strong bots, but with this version that advantage seems lost.

--Vic

140 or 180 doesn't matter much I think. What matters for my (and Raiko's) gun which both have rigid indexing boundaries is that those power 3 bullets resides in a slice by themselves and do not contaminate the stats for "normal" bullets. What matters for you more is probably where your gun starts hitting the enemy really easily as to allow you to fire power 3 and collect maximum points. The balace between survival and bullet damage is delicate. But I think it's always best to maximize damage. Survival is best built with good movement and accurate targeting. You're closing in on Tityus now I see. Since T has a movement that performs comparable to Raiko's that can only mean your gun is starting to work as good as mine does. And my gun is pretty good, if I'm allowed to say so myself. It's soon time for you to explain in more detail how your gun works. =) -- PEZ

Soon, PEZ, soon.... :-) The bug was only small, so your firepower management has in the end gained me 9 points. Hopefully your other tips will prove to be equally productive :-) I think I will need to experiment more with firepower management in the future, but right now I'll concentrate on other stuff.

--Vic

You probably know this already. But anyway, to get a stable rating you need to let the bot get some 650+ battles. At 500 it is very unlikely it has met all opponents and from there the rating can vary quite much. -- PEZ

Yes I know that, and I always wait for that. Maybe you observed me changing a couple of scores on this page? That was because it still changed a bit even after 650 battles. --Vic

TimeSinceLastVelocityChange didn't change much over TimeSinceLastDecelleration. But maybe in combination with segment lastVelocity it will make a difference, so I'll leave it in for now. --Vic

Yes, segmentations can interact in interesting ways. -- PEZ

I've added a BulletPower segmentation dimension. This should take care of the theoretical d==180 indexing boundary problem. It also will mean that there is now adequate segmentation on Distance. combining BulletETA and BulletPower will do that, right? --Vic

Yep. Since you nail down the other parameter to bullet flight time it should be equivalent to distance segmentation. -- PEZ

This version hovered around 1885 for a long time, but eventually settled at 1879, so again +2 rating points. It seems that after 626 battles no more are being fought, so I'll take this as the score for now. But more importantly, the PBI graph looks much more balanced. The difficult mid segment of bots seems overall higher, and there are less extreme problem bots. --Vic

That's great. I think a balanced PBI graph is a really good sign. -- PEZ

Yeah, although that did not really translate in a higher rating.

Next up: I've added the lastVelocity dimension. Hope it will work....

--Vic

The rating system is really weird. I tend to concentrate more on the PL performance and the balance of that PBI graph. From there it should be comparatively easy to exploit the peculiarities of the rating system I think. -- PEZ

I also very much like the PL rating. Too bad it does not update in real time, or I might be tempted to use that for version comparison. So how often does it update anyway? --Vic

Twice a day. But it has an element of luck to it so I think it could be dangerous to use it for any definite decisions. Add "&table=2" to the URL and you'll get a raw average %score figure that I think is less arbritrary. The PBI graph gives the same info actually. If you just "zoom out" and consume the big picture. -- PEZ

Yes, I can see that element of luck you mention. The PL rating is much more vulnerable to the shortness of the matches than the ELO rating is. Especially when you and your opponent are about equally matched. In that case it's just a flip of the coin really. The PL system only takes a one bit boolean (win or lose) as input, while the ELO system takes a double (win ratio) as input. So you could say that the sample bit depth of ELO is much higher. So how is this "raw average" calculated? You mention it's like the PBI graph info, so is it the average win ratio of all matches fought? --Vic

Yes, it's an average of each bots share of the score. The same info as feeds the ELO ranknings. -- PEZ

Next up: I removed the RelativeHeading dimension. Your tests showed that it did not work for you, so I will try removing it completely. In theory it should improve learning speed, and make all other dimensions much more important relatively. Let's see what happens. --Vic

Mind you that my tests where with the TargetingChallenge. You've got my complete attention with this gun experiment of yours I tell ya! =) -- PEZ

Ok, it seems after 565 battles Locke has already had all the pairings under its belt. The score is: 1967, meaning down 9 rating points on removing the RelativeHeading segmentation. My guess is that the pros on this segment outweigh the cons in my case. I must note that in my gun RH is currently the most important segmentation dimension. I've weighted it a factor 100 (!!) heavier than all other axes. In practise that means that it's practically a fixed segmentation. So, PEZ, maybe there are a few points for you to gain here after all. But now I would suggest if you try this again, you should weigh this segment in very heavily. In theory all this makes sense to me. This dimension should have a real impact, so if it doesn't work in your gun, maybe there's some counter effect with segmented GF guns that do not occur in my gun. I don't think it is learning speed, because most bots will move in one RH segment anyway. Maybe it is the fact that you have to take another segmentation dimension away for memory purposes?

Next test: Again I will try firing waves every tick. It didn't really work last time, but with all these changes I'll give it a go again. Maybe it is the combination of all your tips that may do the trick. This will be the last of those that I have on my list, btw. So next up I will remove the things that did not work for Locke's gun and hopefully in the end I'll have gained 10+ points with this testing branch.

--Vic

• 1876, That's +9 rating points! The last attempt at this did not gain any points, so that's kinda weird. It could be explained by the fact that I now have much more segmentation dimensions, slowing down learning. Also, the influence of 'reversal segmentation' (segmentation on TimeSinceLastVelocityChange, Velocity, LastVelocity) has increased relative to the others by the removal of the RelativeHeading, and the addition of the LastVelocity segment. And this reversal segmentation needs lots of data to become useful, as explained by PEZ somewhere else on this wiki. --Vic

Hehe, i am the logo-man today...Googling on Philosophy i find one 'bot' after another. How about as a logo?
This |Locke may not be the Locke you named your bot after, but it is another great philosopher (like Aristocles) --Loki

• Thanks! I'll take it :-) Actually this bot is named after the Locke you mention. Just in an indirect way ... it was the pseudonym of a character in the book Ender's Game. BTW, good to see you here again! It's been lonely in the dutch camp lately.. --Vic
• sorry i left defending the Dutch honour to you alone, but i see you are doing a great job! I have been (and still am) working on a project that leaves me very little time for Robocode. Apart from my normal working week a lose some 4 to 6 hours a day in the traffic. The time remaining is for the family and basic things like eating, sleeping...It's amazing to see how fast development in the Robocode world takes place. As soon as i get some more spare time i first have some huge catching up to do :) I will try to at least visit this place more often. succes --Loki

Next up: restoring the RelativeHeading dimension. --Vic

It doesn't seem to matter all that much what segmentations you do. That's a bit curious I think. -- PEZ

It doesn't? Is minus 9 not significant you think? What range of points would you have expected to be gained or lost? --Vic

9 points is a difference. But I would expect the differences to be bigger when throwing segmentations in and out like you are doing now. Maybe I should try with CC. Suggest a segmentation going in or out of CC please. -- PEZ

Wait. You didn't fire waves every tick before? Man. Had I known I would have suggested that first thing! -- PEZ

You did suggest that before. And I did test it then =) But it didn't work too well at that time.

I'm suspecting that the amount of impact (or better: lack of impact) of these tests is inherent to this gun's design. My segmentation is much more fuzzy than the rigid segments of your type of gun. I'm not sure yet if this is going to prove to be an advantage or a disadvantage.

Are you asking *moi* to suggest segmentation for CC? =) Well, I only would suggest that you try RelativeHeading one more time. I've been trying to figure out how that would have to be done with fixed segmentation. In Locke's case RelativeHeading makes sure that only collected waves that have the same, or very similar, RelativeHeadings are grouped together. That would translate for fixed segmentation in one of these possible solutions:

1. use an absurdly high number of segment divisions (Locke has 127!). That would explode your memory consumption so that's just not practical. But if you want to try, go for say 20 divisions :-)
2. use less divisions, but use a non-linear scale, with more detail around 90/-90 degrees, and more coarseness at around 0/180/-180 degrees. For instance, use these 8 RH segments: -180:-95, -95:-90, -90:-85, -85:0, 0:85, 85:90, 90:95, 95:180.
3. I know ABC takes the abs(angle), but I have no idea how he compensates for clockwise/counterclockwise. But if you can wrap your mind around that, you could double the granularity like so: 0:75, 75:85, 85:88, 88:90, 90:92, 92:95, 95:105, 105:180

Good luck :-) I'm very curious if and how this would work for you! --Vic

I'll try 11 with absolute values. Accounting for clockwis/counterclockwise shouldn't be necessary since I'm using GuessFactors to begin with, should it? -- PEZ

Well...if it's that simple, why am I not using that? (slaps head and decides his mind is cooked for the day :) --Vic

I might be wrong and that might be why it doesn't work... -- PEZ

Yeah! 1888 rating points! that's +12 compared to the previous version without the RH segmentation! And ... small detail ... I have passed Tityus in the rankings =) It seems the more segmentation axes I have, the more positive impact comes from firing waves every tick. The PBI graph is now very curious: I'm stronger against the wavesurfers, and stronger against the majority of the midrange bots, but I am suffering from some terrible problem bots again. The same names as before, but worse PBI indices. Maybe just because I did not improve against those bots, while my rating has gone up...

Anyway, that's the end of the PEZ branch. You helped me gain 18 points, man! Thanks a lot for that!

--Vic

Great! And there seems to be lessons in this for me too. Must sort it out. And I must be doing something wrong with RH segmentation because I lose lots of rating points when I use it. Yes, firing waves every tick is only necessary and beneficial when you have lots of segmentations. That's the Raiko lesson once again. =) -- PEZ

---

version 0.6 discussion:

In the 0.6 branch I will concentrate on the ordering of the log. While browsing through the code, I suspect that this may not be without some design errors. First up, I will test a faster algorithm for searching the log. I don't expect to gain any rating points, except if the previous algorithm was buggy. --Vic

Ooops... lost 11 points. But I found two small bugs, although I doubt that these result in -11 points. But you never know with robocode... --Vic

1881 with the bugs fixed. Thats still -7 points. It seems the old algorithm works better, so revert, revert, revert.... --Vic

version 0.6.1 fixes a design error I found in the log re-ordering algorithm which caused some observations to be moved to a worse place in the log. --Vic

1879! That's -9 points, and I am SO sure that this is a genuine fix! I think I may have a real problem with log ordering. Must find out. --Vic

0.6.3: A desperate attempt to see how much the log ordering influences the rating. I've increased the search loop size so there's a bigger chance to find the optimal neighbourhood, so Observations can be inserted and re-inserted better into the Log. Trying to exchange performance for rating points. --Vic

Well, it's good I checked the rumble progress before going to bed! I'm very pleased with its performance so far. +10 points seem within reach, but more importantly it gives the top bots a hell of a scare, which is convincing me that I'm on the right track. Locke 0.6.3 is a problembot for all 1900+ ranked bots except SandboxDT and Lacrimas!. Furthermore, Locke beat SilverSurfer, BoxingVirus, Aleph, Pugilist, Tron, Okami, YALT, PulsarMax and BlestPain and it gave RaikoMX and CassiusClay a near loss... Of course, there are 250 more matches to run as I write this, but I'm pleased already. I think I'll sleep well tonight :-) --Vic

DT and Lacrimas are two really tough bots to beat. Those scalps you've gotten there make a hella nice price shelf! -- PEZ

Aaargh... that is disappointing! Locke fell back to 1890 points. Well, it's a small improvement anyway so I schould be glad, although I doubt if those few points won will justify the performance penalty. But, on a more positive note, the PBI graph looks much more balanced compared to version 0.5.10.8 so I guess I'll keep this configuration for now.

About DT and Lacrimas, these bots have amazingly flat PBI graphs. Especially Lacrimas. Does anyone have any idea how iiley managed to achieve that? Is there a trick involved?

• Oops, I actually meant BlestPain, not Lacrimas. BlestPain is the one with the extremely flat PBI index. --Vic

--Vic

The RoboRumble is sometimes a very strange beast. My 0.6.4 hack was not supposed to lose 8 points! In the coarse search_the_log function I now started at a random point to avoid streaks of missing global minima. I cannot understand how this can be worse than starting at a fixed point. Maybe I am simply wrong. Have to think it over... --Vic

Yes, a true GhostBuster must stop guarding her/his sanity. =) I think that to get a better measure on your gun you should switch off the MusashiTrick in your Raiko movement. Since that trick take advantage of a weakness of the rating system your rating can be very influenced by your guns performance, or even luck, against a few head-on targeters. -- PEZ

My sanity is lost beyond repair anyway, so no worries there :-) I need the MusashiTrick to compare my rating with that of Raiko. But it could be very true that this trick increases the margin of error. I'll try reentering a previous version under a new version number to check that out. Bumping the above topic: Does nobody have any clue why BlestPain has such a ridiculously low specialization index (8!) --Vic

Release a Raiko without the MusashiTrick too and use it for measure. It would be good to have there for anyone doing gun development. Especially since Raiko's gun might be the best RR gun out there yet. About BlestPain, I don't think it holds the record in low specialization index, but it's certainly one of the lowest. To get that you need a genuily good movement and likewise gun I guess. That RaikoNMT bot might well compete. =) -- PEZ

Great idea! one RaikoNMT coming up .... So who is the current holder of the record of lowest specialization index then? --Vic

• Dunno really, but Quest has 6.8 and Sedan has 7.7. And ad.last.Bottom somewhat proves me wrong on my statement above. I guess you can reverse it totally too. =)-- PEZ

Yeah!

Fighting battle 0 ... axeBots.SilverSurfer 2.33.2,vic.Locke 0.6.5 RESULT = vic.Locke 0.6.5 wins 3185 to 2058

=)

--Vic

PEZ and ABC (and others who might feel adressed), would you consider releasing a bot (p:Zlatan?) made of Raiko's movement without the MusashiTrick, and your guns? I have a feeling that your guns might be even better then Jamougha's within the RoboRumble environment. I'd like to see and participate in that competition! --Vic

I'm pretty sure my gun isn't better than Raiko's. But it's easy enough for me to put that bot together. I'll do it. wiki.RaikoNMTBee or something. My guess is it'll trail RaikoNMT by some 30 points. -- PEZ

30 points? I think you are underestimating yourself big time! But we will see.. How about naming this competition something like ... BestRRGunChallenge? --Vic

• It looks like I am going to be right =) You are just like Germany, PEZ: creating an underdog position for yourself, and then proving that wrong ;-) Bee trails Raiko by only a few points. (but still 100+ matches to go) --Vic
• Nah. I just think that my movements are well up to the standard of Jamougha's. Yet all my bots in the different categories trail his by 30+ points. And RaikoMX lost 40+ points by using the Pugilist gun. (Maybe you missed the gun experiments discussed on the SilverFist page?). If the RRGC ratings passes the test after 650+ rounds I guess it indicates that I have succeeded in improving my gun in CassiusClay. That would feel really good. -- PEZ

RRGunChallenge? -- PEZ

• No, I didn't miss them, but they were not in my immediate memory neighbourhood either :-) Time for me to submit my LockeRRGC. I think I have a lot of work still to do to catch up with you guys. --Vic

Deal! --Vic

Come one Vic, eye on the prize. Lets try and push one another to the 2K mark. We are neck and neck now. I have a small tweak that I am testing now that I think can get me over the 1.9K hump. Cooperate and graduate. =^> -- jim

You don't think it would be some pretty good gun Vic would have to produce to reach 2K with non-adaptive RandomMovement? =) -- PEZ

It would have to be a heck of a gun. But I do not think it possible to do so. I believe the combination of very good guns with very good movement will beat a great gun with just above average movement. Maybe I am wrong to feel that way but I always have. On a side note, how do you make sure that your enemy gets at least one measly point? -- jim

(edit conflict) What PEZ said! I have no doubt you will leave Locke way behind with your WaveSurfing movement. I've seen it happen with PulsarMax, Shiva and Ascendant recently. But rest assured, jim, when I'm pleased with this gun I will move on to movement and go for 2K! And beyond! --Vic

I wish you good luck then! I was hoping to get a little Jam v. PEZ micro.* competition going as it seemed to serve those two pretty well. I have no doubt you will make it to the top. If you have not done so already, try adding a segment in for when you are using the Musashi trick and you are not. I have found that when you move predictably some of your enemies will too. This in effect also polutes your own stats. Adding that segment was pretty killer vs. VertiLeech. If you have not add it and run 100 or so vs. Verti and then actually watch a 35 round match. It is quite funny. -- jim

Thanx! That's a good tip but I will not use it. I'm not creating this gun to be permanently on top of Raiko's movement. When I get going with my new movement -the design is ready- it will not use the MusashiTrick, but be completely adaptive like todays WaveSurfers. But it's not WaveSurfing of course because as always I want to invent something new =) But anyway, I still will compete with you until Locke reaches about 1930 I think. So until that happens the fight is on! --Vic

Version 0.6.5 did not gain me any rating points. But the PBI graph looks more balanced and I believe this tweak will be very beneficial in the 0.7 branch when the log order becomes even more important than it is now.

Next up: reducing the RelativeHeading weight from 100 to 10 (all other dimensions have weight 1 at this point)

--Vic

From version 0.6.7 onwards Locke will not have the MusashiTrick in its arsenal, since I'll be comparing it with the entrants of the RRGunChallenge. But right now I will need to keep LockeRRGC to finish, since that is my new benchmark. That will mean that until the LockeRRGC has finished I have two similar bots in the Rumble. But be assured, it's only for a few hours, and I am running two clients on separate computers to help speed up the process. I have been running two clients regularly for the last few weeks now, sometimes even when I had no updated bot in there. Just collecting some Karma ;-) --Vic

Reducing the RH weight had hardly any impact...which is good, because it allows more room for the other segmentation axes. I'll try reducing some more later on.

I've experimented with adding another segmentation on EnemyBearing. In theory this should work better against any enemy movement that reacts to my movement. Of course that means mirrorers, but my guess was that a lot of bots may have this small amount of predictability. but, I was wrong. Lost 7 points in the process....

Next up: some bullet power tweaks. First of all, BP=2.0

--Vic

Basically I'm not expecting the 0.6.8 branch to do a lot pointwise. Just submitting some small tweaks to see if the ranking is indeed more stable without the MusashiTrick.

Next up: conserving firepower when me or enemy is low on energy.

• I did not expect this! What a nice surprise! +7 rating points for such a minor tweak! The credits here go to Jamougha, who's elegant one line of code I used.

--Vic

Please don't hate me, ABC! I just can't keep Locke under control :-/

abc.tron3.Shadow_3.07 61.8 1 22-6-2004:14:33 34.8 27.0 
abc.tron3.Tron_3.06   55.0 1 22-6-2004:14:24 41.9 13.1 

-)

--Vic

impressive! And how about this one:

apv.ScruchiPu_1.0	 99.7	1 22-6-2004:14:51	60.3	39.4

did you cause ScruchiPu to "throw exceptions" instead of firing bullets? --Loki

Yeah, I've seen that a few times before. It's a very sporadic occurance so I never thought much of it. It's weird though. --Vic

It happens all the time with Pugilist against ScruchiPu. -- PEZ

---

Now that's weird: when going from 1.9 to 2.0 bulletpower I lost two points. Now when I go from 2.0 to 1.8 I lose 12 points! That's an awfully big difference. Hopefully 1.9 will restore those lost 14 points completely..... Can anyone explain that big difference? --Vic

Not other than that 1.9 is probably more optimal against the whole range of bots than 1.8. The difference between 1.9 and 2.0 power is too small I think. But it's not a coincidence that Tityus, Raiko and Pugilist use power 1.9. It's proven to be a very good choice of power. =) -- PEZ

Actually Raiko uses 2.0, that's why I tried it. But it looks like 1.9 is the better choice. --Vic

Gotcha! Raiko and Pugilist and that family of robots uses either 1.9 or 2.0 in different versions. It's not because 2.0 is better. It's because it saves 3 bytes. =) -- PEZ

Haha! What a great reason for using 2.0 :-) 1841 at 512 matches.... still 6 points below the 2.0 version. Something isn't right. I think i'll run the 2.0 version a second time and see what happens. Maybe it was that ScruchiPu fluke or something in the previous 2.0 version... --Vic

---

I guess summer has struck again. Why robocoding when you can do fun stuff outside in the sun, right? Me too, but also I've been a little busy with work lately. Mind you, I have by no means retired.... I have some stuff up my sleeve yet! :-) --Vic

Version 1.7.5.2 is going good. Are you nervous? -- PEZ

No, not really. I am expecting at most a slight improvement. Like you, I also noticed it started out real good, but I saw that it caught a Scruchi-pu match and many top bot matches early on, which always boost my ratings. 58% against the current king does feel good I must admit :-) --Vic

Can you describe some how the Observations are compared? Are some situational parameters more important than others? How "deep" is a situation? And such. =) -- PEZ

Ok, I'll give you a sneak preview (I had planned to write a detailed desciption when I am happy with the gun):

The gun can basically be split in two major parts:

1. filling the Log with data
2. aiming

Filling the Log goes like this:

• a wave is fired every tick
  • along with the wave situational parameters are stored
    • an array of Situational parameters is called a Situation
    • one situational parameter is called a Dimension
• waves that hit the enemy are processed and removed from the wave manager
  • the path the enemy travelled since firing the wave is stored in a pair of doubles:
    • distance travelled
    • angle travelled (0: straight forward, +-180: fully reversed, 90: 90 degreees clockwise, etc.)
  • the Situation and the distance/angle data are combined into an Observation
  • the Log searches for the index where the corresponding Situations match the Observation most closely
  • the Log inserts the Observation using that index

Aiming goes like this:

• the current Situation is assessed
• the Log searches for the index where the corresponding Situations match current Situation most closely
• the Log determines the positive and negative offset boundaries (resulting in a small subset of the Log)
• a GuessFactor array is prepared
• every Observation in this subset is processed for Multiple Choice using the GF bin:
  • if the distance/angle travelled takes the Observation outside the battlefield it is discarded
  • the distance/angle travelled is converted into a GuessFactor
  • the GF is added to the corresponding GuessFactor bin (if the botwidth spans multiple GF bins, these will be filled as well)
    • closer (more similar) Observations get a higher weight in the multiple choice
• the winning GF bin is converted back into a firing angle and returned

Searching the Log goes like this:

• an outer loop iterates through the Log in a maximum (currently 50) number of iterations
  • in each iteration the Observation is compared with the given Situation
    • the compare function returns a value: lower is more similar
• the closest Observation found by the outer loop is used for a finer search
  • this finer search is done by an inner loop that iterates through +- 300 (currently) adjacent Observations

Comparing Situations goes like this:

• weights for all Dimensions are determined
• a loop iterates over each dimension
  • the difference between the comparer and comparee (squared) is multiplied by the Dimension weight and added to the grand total
• the grand total is returned

Currently I am using 10 Dimensions, and I'm planning to add at least three more very soon. One of the advantages of this system is that there is practically no limit to the number of Dimensions you can use.

--Vic

Thanks! I had a hunch about the basic scheme it seems. I think my next gun will be in this style. Resin failed, but it has some similarities and might work as a start. Now, I guess I'll have some reading up to do on the MultipleChoice issue. I take it the Situations are built on state at the time of fire? -- PEZ

• Yes. About your next gun: it's great that you may build something similar. That way we can share experiences. --Vic

---

What are blind man's sticks? --Ph

It's a BlindMansStick. -- PEZ

---

Tomorrow morning I'm going on a three week holiday :-) To the sunny country of Italy! Hopefully I'll return relaxed and with a few good ideas to help Locke get to 1880+ points ;-). Secondly, I hope to really get started on my new movement system after this vacation. Thirdly, I'll be thinking about the 'other' targeting algorithm we've been busy with in the last few weeks and hopefully come up with something useful. See you then! --Vic

Fijne vakantie! -- Jonathan