Improvements

Jump to navigation Jump to search
Revision as of 27 May 2013 at 01:39.
The highlighted comment was created in this revision.

Improvements

Wow! This is probably the closest a stable PM bot has ever gotten to dethroning LBB 1.69e. It only has about .3 APS to go!

It seems like we could gain that much just by fine-tuning constants. Any suggestions?

    Sheldor16:26, 28 April 2013

    Yeah, clearly less aggressive distancing and bullet power helps out a bunch here. Now that we've changed the default distance we also need to change the reverse probability, all those need to go to 29. Also, I really wonder if there isn't some way to reduce the number of sacrifice rounds at the beginning against top-bots. Perhaps have something like what I do in Toorkild with using total enemy damage received to trip the movement modes instead of number of deaths.

      Skilgannon21:52, 28 April 2013

      Hmm, fewer exploitative rounds would almost certainly increase PL--er, PWIN, but it might reduce APS against weak bots. I suppose we could try going back to four rounds of exploitative movement and see if that helps.

      I don't see any plausible mode-selection other than the one we have now. The amount of Codesize we have to work with is far too small to even implement something like Splinter's, let alone Toorkild's.

        Sheldor23:47, 28 April 2013
         

        You could always enter a few new bots that LBB doesn't have data on. ;) Seems kinda cheap, but hey, you live by the black book, you die by the black book...

          Voidious23:09, 28 April 2013
           

          I wonder what would happen to the ranking if hideEnemyNames was set to true.

            MN15:26, 29 April 2013
             

            Would we be able to save a few bytes by eliminating unnecessary casting? For instance, we could make BULLET_POWER an int constant so the anti-ram doesn't have to be cast to a double. (Plus, 2 hard-coded as an int is two bytes cheaper than 2 hard-coded as a double.) Also, we could make DISTANCE_FACTOR a double constant so it doesn't get cast as a double when we use it to divide getVelocity().

            I'm somewhat surprised by the ~0.1% drop in APS after changing match length reduction. It seems it tried too hard to predict random movement and got fooled more easily. I guess we'll go back to 1.1.4's method, unless you have any other ideas.

              Sheldor (talk)02:39, 27 May 2013