Smart bots competition

Jump to navigation Jump to search

Smart bots competition

As we know, there is hard (bad badly controlled) maximum processing time per turn allowed per bot imposed by the robocode engine. This pushes all of us to do the best in the allocated time limit. But as result some of potentially better but slower strategies do not show up at the top of the rating.

I am looking for a way to set/control allowed calculation time per in the rumble clients, in a hope to find the best among slow and wise bots. So we can start new rumble codenamed "wise slopokes". Additionally, it may spark new wave of interest among the kings of the rating authors.

What do you all think about this idea?

Beaming (talk)17:13, 11 October 2014

I like the idea of more processing time in order to attempt more complex stats, but to be honest I've tried some pretty complex stuff (including Spectral Clustering) for KNN on recorded data and nothing has beat simple KNN with a square kernel and weighted on sample distance. Not to mention that a lot of these algorithms aren't just a constant 50x slower or whatever, they essentially become unsolvable at sizes above ~500 data points, scaling quadratically or worse.

A problem with unlimited processing time is that it becomes possible to simply keep a copy of other bots and simulate them to determine where they will shoot/move.

Does anybody have any specific techniques that they would use if there was more processing time available?

Skilgannon (talk)18:03, 13 October 2014

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:User talk:Beaming/Smart bots competition/reply (2).

I also have a crazy idea of a fine control of the motion, i.e. something more complicated than a simple go to a point which does not change for a several ticks. I want to have a path with smaller/different rotation angles and potentially speed which does not accelerate to max or min state. This produces a lot of possibilities for the paths and takes a lot of time to properly evaluate the danger. Of course it is overkill since such paths are often only 1 pixel apart.

I think DrussGT has a trick where at every several ticks the bot rotates to left and right, so the bot moves in wave like path. This confuses a linear targeting quite a lot.

Though, my goal would be to fit in between coming bullets with a fine control of a motion and also meet a wave with bot moving.

Beaming (talk)00:23, 14 October 2014
 

I had some movement algorithm things in the works, and they would have been more straightforward to implement with more processing time sure, but half the fun so to speak was coming up with the right optimization strategies to make it very fast.

Honestly, overall I don't feel like higher per-tick processing time would be too helpful at this point. My reasoning is, high level Robocode tends to require a very large amount of automated testing to know if some tuning was was actually an improvement or not. If the processing time limit was increased, it would also increase how long that testing takes.

Basically, I think the potential gains from slower algorithms are outweighed by the gains of faster iterations during tuning/development.

If anything I'd be more interested in a "FastBots" league, except I think the engine's control over the processing limit is too unreliable/unstable for that to be reasonable.

Rednaxela (talk)18:36, 13 October 2014
 

Well I wouldn't mind implementing full and proper n-wave surfing, right now Nene just does 2 wave surfing in simple way. Full n-wave would be very time consuming to calculate. But I am unsure of any major improvement it would bring to movement.

Chase18:58, 13 October 2014
 

Slow but functional class of algorithms would be Monte Carlo methods. The more time you give them, the stronger they become.

MN (talk)15:24, 18 October 2014