New Rumble Categories

Jump to navigation Jump to search

New Rumble Categories

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Users.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page.

 

Return to Thread:Talk:Main Page/New Rumble Categories.

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
 

In my model, you could submit any bot to any category, but it would skip turns if it took too long for that category. So time limits implemented the same way they are now, but with different categories.

Straw (talk)04:04, 19 March 2014
 

The problem I have with this idea, is that the Robocode engine's control over CPU time is far too approximate for that task.

The nature of such a league is to encourage people to push the limit of the alotted CPU time, however one can expect the calibration of CPU time to be off by wide margins between different computers, or even different runs on the same computer.

If one wants to have a league where the CPU time is a primary design constraint for bots, we need an engine with more precise management of this, such as by using Java bytecode instrumentation to assign fixed costs to different Java bytecode instructions... but that... that gets very complicated to implement.

Rednaxela (talk)18:49, 20 March 2014

I agree that would be the best way, and also very expensive to implement. If the VM itself tracked it, that would be another story, but as far as I know, it doesn't.

Chase17:14, 23 March 2014

what would happen if the VM itself tracked it

Tmservo (talk)17:38, 23 March 2014