Fixing bugs ... reduces score?

Jump to navigation Jump to search
Revision as of 22 March 2013 at 12:48.
The highlighted comment was created in this revision.

Fixing bugs ... reduces score?

So I fixed several bugs I found in AgentSmith when I added a load of debug output to my bot ... and I discovered my TCRM score reduced by 2% over 30 seasons. Sigh. Do you prefer bug free robots or higher scores? :)

    Wolfman12:54, 22 March 2013

    We had an extensive discussion about this at one point. In the end I think most of us felt a bug free robot was better then a slightly better scoring buggy robot. Since it made it easier to improve its score later, etc.

    I think Voidious mentioned he figured out why the bug caused a score improvement and reintegrated it into the robot in a controlled way.

      Chase13:16, 22 March 2013
       

      I think you have what are called Performance Enhancing Bugs.

      Basically, if you care about the short-term performance of AgentSmith, leave it in. But, it's usually better in the long run, especially this early in development, to keep it as bug-free as you can.

        Sheldor13:16, 22 March 2013
         

        What I do is try to figure out what effect the bug was having, and understand why it caused better results. Then I try to add that effect back in a 'legitimate' way.

        An example is when I gained score by removing the variable-bot-width, which accounted for the extra area the bot covers in a wave if it is moving while the wave crosses. I later added in precise-intersection code, which gained me more score, despite (theoretically) doing roughly the same thing as what had cost me score previously. I chalked it down to my previous method not being accurate enough.

        If this was a bug in a GF gun that helped you only against wave-surfers, I'm not particularly surprised. After all, you were using something that they weren't designed to dodge.

          Skilgannon13:23, 22 March 2013
           

          No it was several things and im only working on the random movement bots at the moment as wave surfers are a whole different thing.

          What I fixed was:

          • My waves were 1 tick behind the bullet
          • Setting the gun angle was 1 tick behind the angle calculation rather than using the latest calculation
          • My automatic weighting was not taking into account the target bots rotation direction.

          Make of that what you will! I'm going to keep the fixes in - as you say it should make improvements in the future easier. Although im currently struggling to find any improvements in the gun at the moment and its way off the leaders TCRM scores. :(

          I guess im too much of a critic and want to be up at the top right away. Or at least better than average.

          Interesting point about the bot size. I'm using the Math.atan(18/distance) * 2 to get the width of the bot. Hrm!

            Wolfman13:34, 22 March 2013
             

            That first one is pretty normal, I do that in my bots because of the physics involved:

            1. the bullet moves
            2. collisions are tested
            3. the bot moves
            4. we see where everything is.

            So our wave should be a tick ahead of the bullet because when the collisions happen that's where the bullet is. You could also do it by having the enemy back one tick.

            I found there was some gain in calculating precise, simulated GF-1 and GF1 instead of just using asin(8/bVel), so that I never shoot outside of where the enemy could be given the setup of the situation, eg walls, heading is not perpendicular, etc. Also, to do a better representation of the bot-size as the wave passes over, check out Waves/Precise Intersection.

              Skilgannon13:48, 22 March 2013