New Rumble Categories

Jump to navigation Jump to search
Revision as of 18 March 2014 at 12:42.
The highlighted comment was created in this revision.

New Rumble Categories

I don't think code size is a good limiter for different rumble types, because it forces people to do all sorts of tricks which results in very difficult to understand code. In addition, code size is so small compared to memory now that it hardly seems relevant in most cases. What if new rumble types were added where time per tick is the limiting factor: QuickRumble, with half the time, FastRumble 1/4, HyperRumble 1/8, SlowRumble 2x, etc. (Names are arbitrary) This would mean bots in faster rumbles would have to make more time tradeoff decisions, (less precise prediction? more approximate GFs?), and perhaps bots in slower rumbles could find a use for non-KNN classification schemes that required more time. What do you think?

    Straw (talk)23:47, 17 March 2014

    Tick time size sound like a fantastic idea, I think robocode has some built in constants which potentially can be tweaked for time based rumbles.

    But, I would still keep size based categories. I personally amazed how much can be squeezed into small code. It is indeed unreadable, but they set a bar and send a strong hint to me when those little gizmos level my megabot.

      Beaming (talk)00:52, 18 March 2014

      I'm not advocating the destruction of the codesize limited rumbles, just the addition of time limited ones.

        Straw (talk)02:11, 18 March 2014
         

        The problem is categorizing them. Right now they are automatically sorted into the categories, since codesize is a compile time constant. However time limiting is a run time value. You would have to run a number of battles to place a robot. Even then you need to decide if something that is under the certain limit 99.9% of the time but over 0.1% of the time should be in which category, and so forth.

          Chase10:13, 18 March 2014

          Well, we can make a time tick fixed competitions. Every one participate but bots which designed with time constrains in mind will sort to the top by themselves.

          I think it is analogous to current size based system: nano bots participate in mega bots competitions and have good chances, but it is not true in reverse. Though here we can participant selection in advance.

          So all we need is good tick measure, which is not that easy with current CPU which tend to throttle and boost their performance.

            Beaming (talk)13:42, 18 March 2014