Talk:Dookious

From Robowiki
Revision as of 22:49, 9 November 2011 by PEZ (talk | contribs) (→‎About your anti surfer gun: What about bots that do not react to bullets fired at them?)
Jump to navigation Jump to search

From old wiki

Wow, I didn't realize your AntiSurfer gun would be so valuable. -- Simonton

I'm surprised! I wonder what you would get it you disabled the flattener as well. -- Skilgannon

Hang on, just comparing with the last version, and it seems like you broke something. You only got 91% against HOF, and several other questionable results. -- Skilgannon

Good catch. What the heck could I have done here... I'll have to check this evening when I get home. -- Voidious

I also just took a peak at Dookiton, and it only got 93% against Barracuda. So it might pay to look a little deeper.. -- Skilgannon

(Edit conflict) I'm not going to do much debugging from work, but I did at least diff the source code briefly just now. I haven't the slightest idea what bug I could have introduced - it seemed like a pretty straightforward tweak. Maybe someone is running the rumble with only 256 megs and Dookious was running out of memory? Or it could just be a real bug in the movement... -- Voidious

If it was a memory issue surely it would be much worse against other memory-hoggers, not HOF. Did you entirely disable the anti-surfer, or just modify your VirtualGuns to not choose it for firing? There might be something in there that initializes a variable that your movement depends on (or maybe the rest of your gun depends on), and it throws an exception if it doesn't get initialized. -- Skilgannon

  • I don't think it's anything like that (and the first thing I did this morning was double check =)). I just removed the gun from the VG array and hardcoded the chooser to pick the main gun. (I have a wrapper around my VirtualGuns.getBestGun to bias the main gun in some cases.) And there's no connection between the gun and movement. -- Voidious
  • Ooops ... That would be me. The default memory setting in roborumble.(sh|bat) is 256m. -- Ebo
  • Yeah, that should be increased to 512 as the default, I think, as it is in robocode.bat. I still can't say for sure if that's the problem with 1.583, but I sure hope so. =) -- Voidious
  • Oh, and about it showing up against HOF. Well, it could be that other memory hoggers also run out of RAM if/when I do, or that it's not standing out that they crush me since I disabled the AntiSurfer gun. I dunno... -- Voidious

Ok, after 1.583b (rerelease) and 1.584, it looks like I get 5-6 points from my AntiSurfer gun and ~2 points (!!!) from my flattener. Two points! It's practically useless. Still only 2 losses (Phoenix and Shadow) in both cases, too. I'll have to look at the stats more closely before drawing any more conclusions, but some interesting data there, for sure. -- Voidious

Very interesting, have you tried running the TC/MC for those versions? I would suspect maybe the 35 round results won't change much, but in 500 rounds there must be a difference? -- ABC

No, I haven't. I suspect the gun would get crushed against the betters surfers in the TC, not sure about the movement. This was interesting, too... I compared 1.584 (no flattener) to 1.582 and sorted by average score. The 50 toughest bots were like -120 total (flattener good) and the 4th toughest segment (151-200) was +60 total (flattener bad); the rest of the segments were basically even. Makes sense, too: flattener helps a ton against the very toughest bots, but hurts a bit against the borderline bots. -- Voidious


The results for Dookious seem corrupted, the details page doesn't show all the matches and your score has dropped below Phoenix. I think a re-release is in order ;-) -- Skilgannon

Word cloud

Beautiful word cloud! So, what is more, double or public? » Nat | Talk » 02:49, 5 April 2009 (UTC)

Not sure. =) I'll have to re-run it and check the counts. --Voidious 13:38, 14 May 2009 (UTC)

Bullet power experiment

I know I lost a lot of points with 1.60, but check out that wicked survival score. =) Over 95%! The change was one I was working on a couple weeks ago.

It uses my old, hand-crafted energy management for the first 200 shots (~5 rounds), then switches to a formulaic energy management system that tries to maximize energy differential. I track my own hit percentage and the raw odds of hitting (i.e., what Random Targeting would get) for all shots. This gives me a way of projecting an (hopefully accurate) expected hit percentage for any situation (since calculating RT odds is easy) at any bullet power. So I test the return on all increments of .01 and choose the best. Optionally (and enabled in this version), if it's a negative return, I don't shoot at all.

Of course, Robocode scoring is not purely Survivalist, so I knew there was an inherent problem with this. But I was having trouble coming up with another way of doing it. Any time I'm obviously going to win the round anyway, maximizing damage differential isn't helping my survival score, and I'm better off racking up bullet damage instead. Maybe I'll tinker with that.

--Voidious 13:38, 14 May 2009 (UTC)

How you did normalized hitrates in 1.60 for finding bulletpower sound exactly what I do in RougeDC. I find it interesting though, if I look here it appears that it lost you overall rumble score but gained in survival massively. This says to me that Dookious 1.60 optimized bulletpower the way that "RougeDC survival" did, by purely optimizing for energy gain. That lost main points while gaining survival (Make sure to compare the "Common % Score (APS)" and "Common % Survival" due to changes in rumble shaking up the scores lots). For example, see the Shadow score here, where it gains in survival, at a hefty overall score cost, because that is what energy gain is naturally about: survival. What I found gained points in both survival and overall, was optimizing a weighted combination of bullet damage and energy gain, which is what "RougeDC balance" does. Of course, the weighting of that combination was just guesswork, and if I wanted to improve it further I could make it adaptively decide that weighting.... :) --Rednaxela 12:43, 2 June 2009 (UTC)

Yes, exactly, I optimized for energy differential. I knew that wasn't the way to optimize score, but I just wanted to try it. It's really tough to purely optimize for score, since that involves knowing what portion of your %-score comes from survival and bullet damage in a given match. Cool to hear you got something that works with some mixing / hand-tuning, though, I should give that a try next time I take a look at that code. --Voidious 15:49, 2 June 2009 (UTC)

Chookious/Dookalk?

Mind if I throw DookiLightning and DookiCape on Chalk to determine which stinks more - Chalk's gun or movement? Thanks! --Corbos 17:46, 27 May 2009 (UTC)

Of course not, be my guest. "Dookalk" almost sounds Klingon. --Voidious 18:08, 27 May 2009 (UTC)

About your anti surfer gun

Could you share what the general strategy is? I'm trying to follow the code, but it's not evident to me still. Do you have special segmentation and/or faster rolling of the stats? If it's the former how do you reason when picking segmentation for surfers? --Curious George 19:05, 7 November 2011 (UTC)

Mainly, it uses a very fast rolling average and lower weight to virtual waves. The common config stuff is in AntiSurfBufferBase (vs MainBufferBase). The rolling depth is 1, meaning a firing wave is weighted equal to all existing data (imagine each hit having double the weight of the previous one). And virtual waves are given a weight of .1 instead of .2 (firing wave weight=1), since surfers reacting to bullet fire should make virtual waves less useful.

The segmentation is separate from the main gun, but I don't think the differences are significant. IIRC I just branched from my main gun segmentation and then kept them separate so I could tweak them separately (it was probably the main gun I was tweaking). It also logs bullet hits negatively, but I don't think that makes much difference, either. --Voidious 19:36, 7 November 2011 (UTC)

Thanks! Trying that lowering of virtual waves now too. As it happens I also have a weight ratio of 1/5 between virtual and real waves. What do you mean by logging bullet hits negatively? -- PEZ 20:50, 7 November 2011 (UTC)

Yeah, CC is probably where I got that 1/5 from originally. =) Basically, a bin loses points if a bullet hit lands there, in an effort to simulate what's happening in their surf stats. I know I was convinced at some point that this helped, but as of now I don't think it makes much difference.

--Voidious 20:53, 7 November 2011 (UTC)

I see. I removed that from my anti-surfer gun a few days ago. Somehow it should help against surfers, but it makes the gun stupid to use against others and I ended up safeguarding against that to the extent that the gun was almost never used, against a surfer or not. BTW, against CC you seldom use the anti-surfer gun it seems. Both guns have similar stats with the main gun most often having the edge. Does that mean CC's surfing is too crude?

Another question, do you roll your VG ratings?

-- PEZ 21:11, 7 November 2011 (UTC)

I wouldn't say "crude"! But I do think it means that you're not rolling your surf stats quickly enough. I think you could dial those rolling depths way down. I guess it could also mean you have some movement tendency (like near wall behavior) that the Main Gun picks up on well enough that it out-weighs what is gained by the fast adapting of the Anti-Surfer gun.

Looking at Dooki's code, I have a rolling depth on the VG stats, but it's higher than the number of shots in a normal battle. I don't roll them in Diamond.

--Voidious 21:29, 7 November 2011 (UTC)

Thanks again! Yes, I'll get to movement eventually. =) -- PEZ 21:47, 7 November 2011 (UTC)

About weighting virtual waves lower than real waves... It makes absolute sense against bots that react on bullets. But doesn't it also slow the learning down against bots that do not? Not that it might not be worth the trade-off and not that I have the slightest clue what to do about it, but anyway. -- PEZ 21:49, 9 November 2011 (UTC)

Flattener strategy

You once said that the mechanism in CassiusClay for enabling the movement flattener had some room for improvement. (CC just assumes that any bot hitting more than X% must be a learning gun and thus tries to flatten the curve.) How do you go about choosing when to enable the flattener in Dookious? -- PEZ 23:45, 7 November 2011 (UTC)

Well, it's even simpler than that at "2+ ranged hits per round". But even if that's very close to using a raw hit %, there's two big areas for improvement that I see:

  • Normalize the hit percentages. A hit percentage of 10% at distance=500 should be considered as accurate as 20% at distance=250. Similarly if you are hit when your precise MEA was cut in half because you were against a wall, that's like being hit at a closer distance. So I log 1 shot fired as normal, but for a shot that hits, I log 1 * (hit distance / some typical distance) * (precise MEA / some typical MEA), because your bot width scales linearly with distance and reachable range scales linearly with precise MEA. (The "typical" divisors are just to give a more readable result for tuning.) I think this is mathematically valid, since I've mentioned it elsewhere and Rednaxela didn't call me out. =) I think he normalizes in a similar fashion.
  • It's dangerous to enable the flattener, so you want to be conservative until you gather enough data. In Dookious, I don't consider enabling flattener for first 5 rounds (like CC does), then I have different thresholds kick in at 5/10/20 rounds. I recently took this a step further in Diamond, where I use a fixed hit % but add a "margin for error", calculated like in election polling, based on number of shots fired so far. That seems to have let me lower the threshold without losing APS, too.

Hope that helps! --Voidious 01:37, 8 November 2011 (UTC)

Well, that's a good enough enough approximation, buuuut since you mention me I'll take that as an invitation to call you out on how technically that doesn't account for:
  1. It's technically 2*atan(18/distance), but at usual distance it is near-linear.
  2. Precise intersection always results in a larger botwidth than the 2*atan(18/distance) approximation, and would give you slightly different results
But yes, generally it's a good enough approximation. :)
About my normalizing in similar fashion, I do for my bulletpower calculation code but not for a flattener purposes, as I don't use a flattener.
Just for the record, I'd also like to note that you don't need a flattener to do well against adaptive bots. IIRC Scarlet (Chase-san's Nene movement) doesn't use a flattener, and look at thescores against DrussGT. Of course, that's partially cheeky bulletpower... but it doesn't always need to :P
--Rednaxela 04:34, 8 November 2011 (UTC)

You cannot post new threads to this discussion page because it has been protected from new threads, or you do not currently have permission to edit.

There are no threads on this page yet.