Changes:
It's kind of funny, but wall smoothing was sort of done by accident, since I no longer had control of travel length for wall avoidance I had to change attack angle, and voila: enter wall smoothing ;) I took it a step further and borrowed Raiko's idea of changing direction if we're going to dive at our opponent.
Lateral velocity and acceleration segments still kind of irk me, I'm going to have to think long and hard about switching back.
Bottom line: Well, not quite my expectations, but still doing reasonably well. I've accidentally gone and made a top-feeder. Will be removing colours for MusashiTrick.
1st: arthord.micro.Muffin 0.4.1 4127 1200 240 2335 351 0 0 25 12 0 2nd: arthord.micro.Muffin 0.4 2739 600 120 1842 176 0 0 14 24 0But that isn't too reflective of the improvement against others as far as I'm concerned.
Changes:
Competitive side of Kuuran's microbot line. Some rough edges and work to do, but overall I'm quite impressed with the spirit this bot has shown :)
| axeBots.Musashi_2.18 | 46.4 | 2 | 2-2-2004:15:48 | 37.6 | 8.7 |
| davidalves.net.DuelistNano_1.0 | 47.8 | 5 | 2-2-2004:19:36 | 60.6 | -12.8 |
0.5: It's old movement wasn't flat enough, so I took the oft stated advice of switching to a simple orbit where I pick a probability of direction change. When approaching a wall it turns along it unless that would bring it into an opponent, when having to turn hard (above 16 degrees) it stops temporarily. There are no more angle variation tricks to try and confuse heading/velocity matchers.
0.6: As above but without the turn assurance and with a different function defining the probability of direction change.
0.5: It uses a stat gun very much along the lines of GuessFactor targetting, segmented on lateral acceleration, lateral velocity and distance.
0.6: See 0.4.x.
Honestly, this technique seems to imbue the bot with much good mojo and inspire good Jarma.
Fixing the wall behaviour wouldn't be bad either.
A few others irk me (anything Duelist in particular) but not to this extent.
Newer versions borrow lightly from Raiko.
Coincidentially, I think you're having trouble with the first two guess-factor-targeting micros with a guess-factor-targeting micro. And the MusashiTrick would destroy HawkOnFire for you, probably. -- Kawigi
Indeed, I think the nature of this problem is mostly due to my movement profile having a large spike (I think it was around 9-10 percent hit rate in flood grapher at mid ranges) around +0.4 and a companion large spike at 0. Oddly, though, an improved profile didn't help it's performance, so I'm not sure. It's wall behaviour is none too flat either. -- Kuuran
This is random neatness: according to ELO calc 2910 to 2452 has the same rating difference as the percentage of score taken :P -- Kuuran
Wow, I lost a good 20 percent or so against Smog. Looks like scanning at fire time really pays off there. -- Kuuran
Would anyone care to forward a theory as to why I'm tied with DuelistMini but losing by huge blowouts to DuelistMicro? -- Kuuran
Maybe you have a movement that better segmentation doesn't help against? -- Kawigi
Well I guess we'll find out since that movement isn't in the dev in any way shape or form anymore.
Query... (edit) err.. actually.. scratch that question, sometimes I'm so stupid I amaze myself. -- Kuuran
No.. freaking awesome.. I guess this release makes it pathetically obvious I didn't test against low-ranking bots at all. I can beat the whole apv package but not half the nanos or anything with a direct gun... yay.. :(
Muffin is now officially a top-feeder :( -- Kuuran
Well.. 0.6 fixed that a bit, but now Muffin lost it's ability to tie RaikoMX and a number of other higher end bots, and there seem to be a few rather arbitrary bots (Wolverine, FloodHT, SmallDevil) that enjoy feasting on and wrecking it. I hope I can figure out why the heck this is and finally get that last bit of potential out of Muffin. Some pms and bots that fire fast bullets seem to be Muffin's biggest "fans". -- Kuuran
I honestly see very little consistent between those three bots that would generalize the problem :-p One robot that's easy to hit, one that's hard to dodge, and one that's hard to hit. -- Kawigi
Yeah, well, I feel somewhat better just having confirmation that there isn't some magic pattern I'm missing, so thanks :). Those aren't the only ones but a few examples of the kind of contrast I'm seeing. I guess there are a whole lot of small things slightly wrong with Muffin.. :( -- Kuuran
The biggest problem I see with it is getting stuck on walls and in corners - especially corners - I imagine that's where your GF0 spike was coming from. Until you solve that flattening it's graph may well lower it's performance. - Jamougha
I agree with the Irish man. One way is to rid your bot of the code where it tries to avoid diving at its opponent when wall smoothing. If that removes the GF0 spike you can try apply it again. Use FloodGrapher to see if you need it at all. -- PEZ
I suspect much of the problem has to do with getting rid of the turn assurance code setMaxVelocity?(0); if(Math.abs(getTurnRemaining?()) < 16) setMaxVelocity?(8); in order to squeeze in the MusashiTrick. I agree it is an issue and you're probably right about the +0 spike (though I was assuming it usually happened at range and simply only paying attention to distances of less than about 400). I'm definitely going to consider what you said, though, PEZ. The only problem I see with it is that the MusashiTrick may start deciding it's been hit near GF1 when it dives at a head-on targeter. That might give me enough space to try a fourth segment, though ;) I'll be taking a good long vacation in my MovementLaboratory this weekend and I appreciate the input from everyone :) -- Kuuran
I don't know the internals of your movement. But if it's anything like Tityus, RandomMovementBot and Raiko then you can do without the turn assurance code by using a longer "blind man's stick" for your bot. Maybe that's what you have already done? Also if you are doing anything Tityus like in your movement you can know how steep you are diving at your opponent. In Tityus I look at how many "tries" I had to do to find a destination within the boundaries for this. Maybe you can make your hit-at-GF1 check consider this? -- PEZ
Yeah, I've calculated that the bot should use a blind man's stick of 117 pixels if it's going to have no turn assurance, that's how long a 90 degree turn at max velocity takes. The reason I thought this might be lack of turn assurance is that it seems to turn a bit, move a bit, then be forced to change direction and repeat in the other way, if it were stopped I suspect Muffin would escape the corner. I've considered looking at the steepness of my approach, yes, but I couldn't find a way to do it without burning too much codesize. Maybe I can do something with how many tries it took to find my angle, though, thanks :) -- Kuuran
According to the FAQ, turn rate is 10 - (.75 * Math.abs(Velocity)). At MAX_V you turn at 4 degrees per tick. 90 / 4 = 22.5 ticks to turn 90 degrees. 23 * 8 = 184 pixels to turn 90 degress. Don't forget to add your saftey margin or you will hit the wall. -- jim
184 is approximately PI/2 * 117. so everithing is allright ;-) -- rozu
(edit conflict) Hmmm, but those 184 pixels won't point all in the same direction, right? So 117 pixels could still be right. -- PEZ
this is what I wanted to say... -- rozu
Yeah, I guessed. Though I don't know the mechanics really. I just have found out empirically that a stick of 0.1 radians laterally is too short and 0.35 radians seems to work. =) -- PEZ
I am not sure. Maybe thats the case but I do not think so. No matter how you slice it you need to turn 90 degrees and can do so no faster than 4 degrees per tick (assuming max speed). They will all point in the same direction only if you are in the worst case scenario (heading right at the wall). You can most likely get away with shorter values if you rarely ever head straight for the wall. I could be wrong. Wont be the first time. -- jim
You're making the same assumption I believe was made in the calculation of 170 that I see for this number in Raiko. In order to calculate this value I used the actual component of movement in the direction of the wall as PEZ and rozu have observed. The sum of 8 * sin(90-4n) for all ns from 0 to 22 is the way I calculated 117. The sin of the amount of turn remaining will be the component of your movement vector in the direction of the wall. This quickly decreases in relevance once you've crossed the 45 degree threshold, the last element is less than 0.3 units. Plugging this sum into Excel now I get 118.6, I seem to remember getting 116.6 at home, so I'm attributing the difference to rounding, I was using extremely long decimal values of sin and Excel seems to be rounding to six places. Oh well.. anyway.. I rounded up for my safety margin and called it 117, if you prefer to use 119 or 120 it won't make much difference. As rozu observed if you apply the 117 length into the length of arc formula you get numbers consistent with yours. -- Kuuran
Funny enough, I think I understand how you come to this conclusion. What you are in effect saying is that your movement is the sum of your movement in the x and y direction. Assuming you are approaching the top or bottom wall, then as you approach the wall and become more parallel to it, you are closing in less and less (I think the term is asymptotic). See I can be taught. Thanks for explaining it :) --jim
Raiko's stick length wasn't calculated, btw; I tuned it to that value over a bunch of battles against DT. It's wall-avoidance is useful, but so is avoiding the opponent's near-walls segment... :-) -- Jamougha
@jim: Yeah, that was the way I worked it out. Anytime :)
@Jamougha: I sort of reasoned that avoiding their near-wall segment would end up using so much field that the parts of field where your profile is actually the ideal and not being modified by your wall smoothing would be evaporating too quickly and hurting your normal profile too much. My mistake on the 170, though, the 170 was so close to my number assuming all your movement was in the wall's direction that I figured you just fudged down a little, sorry about that ;) -- Kuuran
Where's 0.6.1 heading? It has only 37 micro-battles yet, but it's details-sheet looks very impressing. You couldn't let me have the #2 spot a while, could you? =) At least tell us what you have tweaked / changed with this release please. -- PEZ
Sorry, didn't get around to updating here yet. The only change is a new flattening formula roughly equivalent to the one in NanoSatan Lambda but it takes into account bullet powers being fired and has a small constant to adjust the results slightly. I think the worst of it's detail sheet is yet to come, though, I'm not sure it'll take that #2 spot back just yet :( -- Kuuran
at least you left behind all the pattern matcher in this category... those new GF micros are some kind of strong ;) -- rozu
Though it remains to see if it's the guns or the movements that accounts for this. Feel free to merge Aristocles movement and your GlowBlow gun to find out. If both fits in a micro, I don't know though. -- PEZ
Thanks rozu :) But don't forget the MusashiTrick we're all using either. I bet Muffin's movement will fit on GlowBlow's gun in a micro any day, Muffin's gun is by far the largest of the three on top. -- Kuuran
How many times must I say it? I AM NOT USING THE MusashiTrick! Sorry for yelling. =) -- PEZ
Looking at GlowBlow's details sheet it definately looks like it could compete for the #1 spot if it applied the MusashiTrick. -- PEZ
Looking at Aristocles's code it certainly looks like the MusashiTrick to me, what's the difference? Actually it's quite similar to Muffin's implementation. -- Kuuran
Here we go again. =) The MusashiTrick (according to mine, Axe's and some other's definition) is to use the time since last reverse and compare it to the bullet flight time to figure out if you're hit at GF1 or not. Aristocles does nothing like that. It simple drives in the same direction, refusing to reverse for anything, be it walls or bots or whatever. Then, when it is hit and it isn't diving at its opponent due to its WallAvoidance, it regards this as a hit at a high GuessFactor. I think the MusashiTrick is better, but I can't fit it in my micro. -- PEZ
I don't personally think a very minor detail change changes what it is. The MusashiTrick is about altering your movement to move to GF1 whenever possible until you're hit and can safely say the bullet wasn't fired direct, if you need to use the last reverse time, so be it; if not, then not. Before I added the anti-diving code into Muffin he did this the same way Aristocles does and I still called it the MusashiTrick, so I think we'll have to agree to disagree on this one. -- Kuuran
OK, let's disagree on it then. I can live with that. =) So Paolo doesn't use the MusashiTrick according to you then. That's a bit funny to imagine to me. -- PEZ
![[Home]](/images/RoboWiki.png)