[Home]Muffin

Robo Home | Changes | Preferences | AllPages


Muffin

Muffin, too, has a /Questions page.

0.6.1: Tweak

Just trying an alternate flattener formula. This one generates some spiking near GF1 but I'm hoping it'll offset the problems with corners a bit.

0.6: Third release.

I realized what was going to be 0.5.1 had so many changes it deserved a new release.

0.5.1: More tweaks than a LAN party.

To be released as soon as I can dream up some way to squeeze a MusashiTrick into it. Currently it's score against DT is better than it's score against Barracuda.

0.5: Second release.

I know I said no more Muffin for awhile, but that was before RaikoMicro.

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.

0.4.1: First tweak.

 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	0
But that isn't too reflective of the improvement against others as far as I'm concerned.

Changes:

0.4: First release.

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

Author

Kuuran

What's special about it?

It is a MicroStatist?, though that is not too remarkable in and of itself anymore. It uses a unique system for determining stat angles that does not suffer from the shortfalls of using something like asin(8/11) for maximum escape area. It's also generally a reasonably competitive microbot.

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

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

How competitive is it?

axeBots.Musashi_2.1846.422-2-2004:15:4837.68.7
davidalves.net.DuelistNano_1.047.852-2-2004:19:3660.6-12.8

How does it move?

0.4.x: It's general movement mode was inspired by iiley's movement (in Smoke, Ash, Spark, et al.), though not actually in any way related to it. It is an oscillator with a pattern break built in by varying attack angle +/- 45 degrees at random on EnergyDrop. It also avoids wall contact (when not near a corner it seems to do so without any visible bouncing).

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.

How does it fire?

0.4.x: It uses a stat gun very much along the lines of GuessFactor targetting, segmented on acceleration, velocity and distance.

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.

How does it dodge bullets?

It's probability to change direction is based on bullet flight time.

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

Not applicable.

How does it select a target to attack/avoid in melee?

Not applicable.

What does it save between rounds and matches?

It saves a profile of the opponent's movement between rounds. Nothing is saved between matches.

Where did you get the name?

GirlPower.

Honestly, this technique seems to imbue the bot with much good mojo and inspire good Jarma.

Can I use your code?

I'm going to say no for an indefinite period here. I would like to OpenSource some more bots, but Muffin is the current mainstay of my competitive line.

What's next for your robot?

I believe my main goal should be to solidify the stat gun's performance and work out the ProblemBots that have so far cropped up. I'm going to consider lateral velocity vs absolute velocity segmenting quite carefully and re-evaluate my choice of movement threshold function. I'm also probably looking at a gun rewrite to use waves rather than virtual bullets, they're quite alot smaller, even if somewhat restricted. I'd like to see Muffin blossom into more of a generalist.

Fixing the wall behaviour wouldn't be bad either.

Does it have any WhiteWhales?

I think the bots I really want to cheer on Muffin's success (present or future) against are:

A few others irk me (anything Duelist in particular) but not to this extent.

What other robot(s) is it based on?

Apoptygma to an extent in gun.

Newer versions borrow lightly from Raiko.


Comments, questions, feedback:

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


Robo Home | Changes | Preferences | AllPages
Edit text of this page | View other revisions
Last edited June 21, 2004 16:42 EST by Ph (diff)
Search: